Skocz do zawartości
Desavil

Problem z Nginx co równe 24h

Polecane posty

Witam.

 

Mam "czystą" instalację DirectAdmina z użyciem konfiguracji CustomBuild 2.0 - Nginx (Proxy) + Apache oraz wersje php 5.5 i 5.6 przy użyciu dla nich php-fpm.

 

Co równe 24h od momentu uruchomieniu Nginxa, wysypuje się on. W pliku z logami znajduje się wtedy następujący komunikat:

2016/01/14 19:02:02 [alert] 64949#0: fork() failed while spawning "worker process" (12: Cannot allocate memory)
2016/01/14 19:02:02 [alert] 64949#0: sendmsg() failed (9: Bad file descriptor)
2016/01/14 19:02:02 [alert] 64949#0: sendmsg() failed (9: Bad file descriptor)
2016/01/14 19:02:02 [alert] 64949#0: sendmsg() failed (9: Bad file descriptor)
2016/01/14 19:02:02 [alert] 64949#0: sendmsg() failed (9: Bad file descriptor)
2016/01/14 19:02:02 [alert] 64949#0: fork() failed while spawning "worker process" (12: Cannot allocate memory)
2016/01/14 19:02:02 [alert] 64949#0: sendmsg() failed (9: Bad file descriptor)
2016/01/14 19:02:02 [alert] 64949#0: sendmsg() failed (9: Bad file descriptor)
2016/01/14 19:02:02 [alert] 64949#0: sendmsg() failed (9: Bad file descriptor)
2016/01/14 19:02:02 [alert] 64949#0: sendmsg() failed (9: Bad file descriptor)
2016/01/14 19:02:02 [alert] 64949#0: fork() failed while spawning "worker process" (12: Cannot allocate memory)
2016/01/14 19:02:02 [alert] 64949#0: sendmsg() failed (9: Bad file descriptor)
2016/01/14 19:02:02 [alert] 64949#0: sendmsg() failed (9: Bad file descriptor)
2016/01/14 19:02:02 [alert] 64949#0: sendmsg() failed (9: Bad file descriptor)
2016/01/14 19:02:02 [alert] 64949#0: sendmsg() failed (9: Bad file descriptor)
2016/01/14 19:02:02 [alert] 64949#0: fork() failed while spawning "worker process" (12: Cannot allocate memory)
2016/01/14 19:02:02 [alert] 64949#0: sendmsg() failed (9: Bad file descriptor)
2016/01/14 19:02:02 [alert] 64949#0: sendmsg() failed (9: Bad file descriptor)
2016/01/14 19:02:02 [alert] 64949#0: sendmsg() failed (9: Bad file descriptor)
2016/01/14 19:02:02 [alert] 64949#0: sendmsg() failed (9: Bad file descriptor)

Serwer posiada 4 rdzenie/wątki oraz 4 GB pamięci RAM - średnie wykorzystanie to 1,5 GB.

W panelu DirectAdmin jest pokazane Użycie pamięci w Monitorze usług - wtedy kiedy Nginx się zawiesi, zawsze pokazuje 1,45 GB. Co ciekawsze, za dnia czasem pokazuje nawet 7 GB użycia pamięci (ciekawe skąd to się bierze), htop pokazuje prawidłowo ok. 1,5-2 GB.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

worker proces - jaką masz tu wartość?

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

worker proces - jaką masz tu wartość?

 

4, bo:

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 60
model name      : Intel(R) Xeon(R) CPU E3-1231 v3 @ 3.40GHz
stepping        : 3
microcode       : 0x1
cpu MHz         : 3392.144
cache size      : 8192 KB
physical id     : 0
siblings        : 4
core id         : 0
cpu cores       : 4
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good nopl eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm arat xsaveopt fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid
bogomips        : 6784.28
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management:

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 60
model name      : Intel(R) Xeon(R) CPU E3-1231 v3 @ 3.40GHz
stepping        : 3
microcode       : 0x1
cpu MHz         : 3392.144
cache size      : 8192 KB
physical id     : 0
siblings        : 4
core id         : 1
cpu cores       : 4
apicid          : 1
initial apicid  : 1
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good nopl eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm arat xsaveopt fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid
bogomips        : 6784.28
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management:

processor       : 2
vendor_id       : GenuineIntel
cpu family      : 6
model           : 60
model name      : Intel(R) Xeon(R) CPU E3-1231 v3 @ 3.40GHz
stepping        : 3
microcode       : 0x1
cpu MHz         : 3392.144
cache size      : 8192 KB
physical id     : 0
siblings        : 4
core id         : 2
cpu cores       : 4
apicid          : 2
initial apicid  : 2
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good nopl eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm arat xsaveopt fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid
bogomips        : 6784.28
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management:

processor       : 3
vendor_id       : GenuineIntel
cpu family      : 6
model           : 60
model name      : Intel(R) Xeon(R) CPU E3-1231 v3 @ 3.40GHz
stepping        : 3
microcode       : 0x1
cpu MHz         : 3392.144
cache size      : 8192 KB
physical id     : 0
siblings        : 4
core id         : 3
cpu cores       : 4
apicid          : 3
initial apicid  : 3
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good nopl eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm arat xsaveopt fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid
bogomips        : 6784.28
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management:

Ustawiłem jeszcze dzisiaj (czyli: 4 [worker_processes] * 8192 [worker_connections] = 32768):

worker_rlimit_nofile 32768;

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

A spróbuj (tak testowo) zmienić 4 na auto.

 

Ewentualnie zmniejsz odpowiednio connections i rlimit, gdyby to nie pomogło.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Zastanawiam się co ten DA kombinuje, że workery się restartują.

 

Jak wywali te błędy po 24 godzinach działania nginxa, to do momentu aż go ręcznie nie zrestartuję, tak "wisi" zawieszony (choć proces jest uruchomiony).

 

 

A spróbuj (tak testowo) zmienić 4 na auto.

 

Ewentualnie zmniejsz odpowiednio connections i rlimit, gdyby to nie pomogło.

 

Sprawdzę i dam znać za 24h. :D

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

 

Chciałbym żeby to tak działało. :rolleyes:

 

Zerknij w cron.daily, wyodrębnij sobie linijkę odpowiedzialną za daily crona DA i ją wyexecutuj, jak głupi to się nawet nie zorientuje.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

 

Zerknij w cron.daily, wyodrębnij sobie linijkę odpowiedzialną za daily crona DA i ją wyexecutuj, jak głupi to się nawet nie zorientuje.

 

W cron.daily nie ma żadnych zadań z DA.

Jedynie w cron.d jest directadmin_cron, a w nim:

* * * * * root /usr/local/directadmin/dataskq
2 0-23/6 * * * root echo 'action=vacation&value=all' >> /usr/local/directadmin/data/task.queue;
#5 5 * * 0 root /sbin/quotaoff -a; /sbin/quotacheck -augm; /sbin/quotaon -a;
0 * * * * root echo 'action=tally&value=all' >> /usr/local/directadmin/data/task.queue
20 4 1 * * root echo 'action=reset&value=all' >> /usr/local/directadmin/data/task.queue
0 4 * * * root echo 'action=check&value=license' >> /usr/local/directadmin/data/task.queue

"Co równe 24 godziny" - miałem na myśli, że od momentu ręcznego uruchomienia/zrestartowania nginxa liczy się to 24 godziny, a nie że np. codziennie o godz. 19:00.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

 

W cron.daily nie ma żadnych zadań z DA.

Jedynie w cron.d jest directadmin_cron, a w nim:

* * * * * root /usr/local/directadmin/dataskq
2 0-23/6 * * * root echo 'action=vacation&value=all' >> /usr/local/directadmin/data/task.queue;
#5 5 * * 0 root /sbin/quotaoff -a; /sbin/quotacheck -augm; /sbin/quotaon -a;
0 * * * * root echo 'action=tally&value=all' >> /usr/local/directadmin/data/task.queue
20 4 1 * * root echo 'action=reset&value=all' >> /usr/local/directadmin/data/task.queue
0 4 * * * root echo 'action=check&value=license' >> /usr/local/directadmin/data/task.queue

"Co równe 24 godziny" - miałem na myśli, że od momentu ręcznego uruchomienia/zrestartowania nginxa liczy się to 24 godziny, a nie że np. codziennie o godz. 19:00.

 

Nie mam pojęcia dlaczego w takim razie.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

I znów to samo (tak od 5 dni już)...

W przeglądarce: ERR_CONNECTION_TIMED_OUT

W ps aux tylko proces (brakuje workerów):

root     57687  0.0 37.4 1571284 1519708 ?     Ss   sty14   0:05 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf

I w logach standardowo:

2016/01/15 19:01:01 [alert] 57687#0: fork() failed while spawning "worker process" (12: Cannot allocate memory)
2016/01/15 19:01:01 [alert] 57687#0: sendmsg() failed (9: Bad file descriptor)
2016/01/15 19:01:01 [alert] 57687#0: sendmsg() failed (9: Bad file descriptor)
2016/01/15 19:01:01 [alert] 57687#0: sendmsg() failed (9: Bad file descriptor)
2016/01/15 19:01:01 [alert] 57687#0: sendmsg() failed (9: Bad file descriptor)
2016/01/15 19:01:01 [alert] 57687#0: fork() failed while spawning "worker process" (12: Cannot allocate memory)
2016/01/15 19:01:01 [alert] 57687#0: sendmsg() failed (9: Bad file descriptor)
2016/01/15 19:01:01 [alert] 57687#0: sendmsg() failed (9: Bad file descriptor)
2016/01/15 19:01:01 [alert] 57687#0: sendmsg() failed (9: Bad file descriptor)
2016/01/15 19:01:01 [alert] 57687#0: sendmsg() failed (9: Bad file descriptor)
2016/01/15 19:01:01 [alert] 57687#0: fork() failed while spawning "worker process" (12: Cannot allocate memory)
2016/01/15 19:01:01 [alert] 57687#0: sendmsg() failed (9: Bad file descriptor)
2016/01/15 19:01:01 [alert] 57687#0: sendmsg() failed (9: Bad file descriptor)
2016/01/15 19:01:01 [alert] 57687#0: sendmsg() failed (9: Bad file descriptor)
2016/01/15 19:01:01 [alert] 57687#0: sendmsg() failed (9: Bad file descriptor)
2016/01/15 19:01:01 [alert] 57687#0: fork() failed while spawning "worker process" (12: Cannot allocate memory)
2016/01/15 19:01:01 [alert] 57687#0: sendmsg() failed (9: Bad file descriptor)
2016/01/15 19:01:01 [alert] 57687#0: sendmsg() failed (9: Bad file descriptor)
2016/01/15 19:01:01 [alert] 57687#0: sendmsg() failed (9: Bad file descriptor)
2016/01/15 19:01:01 [alert] 57687#0: sendmsg() failed (9: Bad file descriptor)

Co mogę jeszcze zrobić, jakieś dodatkowe debugowanie włączyć, czy coś, aby ustalić przyczynę?

 

Dodam, że DirectAdmin jest uruchomiony na wirtualizacji KVM (CPU w trybie Host).

Edytowano przez Desavil (zobacz historię edycji)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

/etc/nginx/nginx.conf

[..]
error_log /path/to/log debug;
[..]
Debug nginxa.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Ustaw limit plików 2 razy wyższy i do tego sprawdź, czy użytkownik, na którym działa nginx nie ma jakichś małych limitów otwartych plików. To jest jedyna przyczyna jeżeli nginx jest w miarę nowy.

 

Jedyny wpis, który znalazłem z tym samym problemem to ten: http://serverfault.com/questions/619337/nginx-out-of-memory-not-loading-new-vhosts

 

Nginx ma problem przy bezsensownych przeładowaniach, gdy konfiguracja się nie zmieniła. Osobiście kiedyś dla testów miałem zrobiony reload co 1 minutę i nic się nie działo, ale zawsze trzymam najnowszą wersję na serwerze.

 

Jak wyglądają wykresy użycia pamięci i SWAP?

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Możliwe, że nie masz ustawionego żadnego swapa i po prostu brakuje Ci pamięci RAM.

Ja tak miałem z MariaDB - restartowała mi co parę godzin.
Wystarczyło wyłączenie buforowania (performance_schema).

Dla nginxa będzie to dodanie w pliku konfiguracyjnym( /etc/nginx/nginx.conf ) lub vhostach
sendfile off;

 

Jeżeli masz oryginalnego DA możesz też utworzyć ticket tutaj.
Ich support jest nieźle ogarnięty i szybko zdiagnozuje Twój problem,

a co najważniejsze napisze Ci krok po kroku co zrobił,

aby go rozwiązać.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Próbowałem zwiększać limity, nic to nie dało.

Pamięci RAM na pewno nie brakowało, co do swap, to jest on wyłączony.

 

Problem rozwiązało.. zamiana Nginxa+Apache na samo Apache. Postawię przed nim prawdopodobnie Varhish'a i powinno być ok.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Problem z nginxem rozwiązało usunięcie nginxa.

 

... OK.

 

Niestety czasem tak trzeba, tym bardziej jeżeli jest to serwer produkcyjny.

Na dalsze ewentualne testy przyjdzie czas. :)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Bądź aktywny! Zaloguj się lub utwórz konto

Tylko zarejestrowani użytkownicy mogą komentować zawartość tej strony

Utwórz konto

Zarejestruj nowe konto, to proste!

Zarejestruj nowe konto

Zaloguj się

Posiadasz własne konto? Użyj go!

Zaloguj się


×