Problem z auktualizacją systemu (VPS)

[baltazar_gabka 0]

Witam.

Od jakiegoś czasu mam problem z moim VPS.

Podczas próby aktualizacji systemu mam taki komunikat:

aptitude update
FATAL -> Failed to fork.

Wygląda jakby było mało pamięci RAM ale polecenie free pokazuje jeszcze ponad 1.9GB wolnego.

free -m -t
             total       used       free     shared    buffers     cached
Mem:          2048        145       1902          0          0         82
-/+ buffers/cache:         63       1984
Swap:            0          0          0
Total:        2048        145       1902

Co ciekawe jak wyłączę MySQL to tego problemu nie ma.

Wyniki z ulimit:

core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 255478
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) 255478
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

Ma ktoś jakieś pomysły w czym może być problem ?

 

 

 

[RafoX 233]

Vps z mints?

[Pan Kot 1535]

Jeśli z poziomu roota dostajesz takie errory to firma przesadziła z oversellingiem .

 

Ew. możesz zwiększyć open files (ja mam 65536), ale wątpię, żeby cokolwiek otworzyło ich aż ponad 1000.

Edytowano Marzec 21, 2015 przez Archi (zobacz historię edycji)

[tgx 575]

Jeśli z poziomu roota dostajesz takie errory to firma przesadziła z oversellingiem .

 

Ew. możesz zwiększyć open files (ja mam 65536), ale wątpię, żeby cokolwiek otworzyło ich aż ponad 1000.

 

overselling bo jest błąd alokacji pamięci? i to wniosek jedynie na podstawie wyniku ulimit? Jaka jest korelacja openfiles a "failed to fork"?

 

warto zajrzeć do /proc/user_beancounters będzie widać jaki limit powoduje ten problem

Edytowano Marzec 21, 2015 przez tgx (zobacz historię edycji)

[Pan Kot 1535]

 

overselling bo jest błąd alokacji pamięci? i to wniosek jedynie na podstawie wyniku ulimit? Jaka jest korelacja openfiles a "failed to fork"?

 

Tak, overselling prowadzi do błędów alokacji pamięci, w przypadku gdy pamięć się skończyła. A failed to fork może wynikać z różnych przyczyn, najczęściej jest to out of memory, limit PIDów lub limit ilości procesów. Z racji, że kolega RAM posiada, procesów raczej nie nawalił więcej niż 32768, a limit procesów wynosi 255478, to zostaje, jak się domyślasz, błąd po stronie matki.

 

Korelacja openfiles z failed to fork jest nieco mało oczywista, ponieważ mamy tutaj związek z wirtualnym filesystemem /proc i faktem, że otwierane tam pliki również wliczają się w limit, a aptitude może źle zinterpretować limit na przeczytanie np. PIDu czy stanu procesu, przez co wyrzuca failed to fork. Rzadkość, ale możliwe do przetestowania w warunkach laboratoryjnych .

[tgx 575]

 

Z racji, że kolega RAM posiada

 

jeżeli to openvz to nie masz na to dowodu i jako że najprostsze rozwiązania są najlepsze to warto poznać limity pamięci z pliku jaki podałem

 

 

 

[Pan Kot 1535]

 

jeżeli to openvz to nie masz na to dowodu i jako że najprostsze rozwiązania są najlepsze to warto poznać limity pamięci z pliku jaki podałem

 

 

 

 

Dobrze to ująłeś - to OpenVZ, i właśnie z tego powodu mówię o oversellingu . Nie znam sytuacji, więc nie będę się upierał przy swoim bo nie mam wglądu w maszynę, ale w 99% przypadków gdy RAM jest zużyty w 10%, a u klienta jest odpalone raptem kilkanaście procesów, to raczej możemy mówić tylko o matce i sąsiadach obok.

 

Ale oczywiście nie żyje w swoim własnym urojonym świecie, więc jeśli to jakiś nowy typ problemu, to chętnie się dowiem o kolejnym możliwym wariancie .

Edytowano Marzec 21, 2015 przez Archi (zobacz historię edycji)