apache i segmentation fault

[qubaaa 0]

Witam. Serwer niedawno zaliczył 2 lata uptime bez większych ingerencji z mojej strony. Niestety od jakiegoś czasu obserwuję w logach nieciekawe wiadomości:

Sep 26 19:28:59 ns310834 grsec: From 207.46.204.224: Segmentation fault occurred at (null) in /usr/sbin/apache2[apache2:31961] uid/euid:81/81 gid/egid:81/81, parent /usr/sbin/apache2[apache2:23531] uid/euid:0/0 gid/egid:0/0
Sep 26 19:28:59 ns310834 grsec: From 207.46.204.224: signal 11 sent to /usr/sbin/apache2[apache2:31944] uid/euid:81/81 gid/egid:81/81, parent /usr/sbin/apache2[apache2:23531] uid/euid:0/0 gid/egid:0/0 by /usr/sbin/apache2[apache2:31961] uid/euid:81/81 gid/egid:81/81, parent /usr/sbin/apache2[apache2:23531] uid/euid:0/0 gid/egid:0/0

 

Czasami dochodzi też drugi objaw: serwer kompletnie zmula do tego stopnia, że parę minut zajmuje się zalogowanie na niego. Wszystko wraca do normy po restarcie apache. Nie mam pojęcia, czy ma to związek z segfaultami - ale niestety nie mogę tego wykluczyć. Niestety poza tym w logach nie ma nic niepokojącego.

 

Ruch na stronie mam obecnie dość przeciętny, w ciągu tych 2 lat bywał on o 25% większy. Po access logu widzę, że googlebot jest dość aktywny, ale nie sądzę, by aktywność ta była większa niż zazwyczaj.

 

Co ciekawe obecnie głupia kompilacja php wrzuca takie kwiatki do loga:

Sep 26 22:17:16 ns310834 conftest[4169]: segfault at 1 ip 00000000004054d4 sp 00007fff895731b0 error 4 in conftest[400000+a2000]
Sep 26 22:17:16 ns310834 grsec: From 89.174.34.11: Segmentation fault occurred at 0000000000000001 in /var/tmp/portage/dev-lang/php-5.3.8/work/sapis-build/cli/conftest[conftest:4169] uid/euid:0/0 gid/egid:0/0, parent /var/tmp/portage/dev-lang/php-5.3.8/work/sapis-build/cli/configure[configure:4168] uid/euid:0/0 gid/egid:0/0

Oczywiście zrobiłem testy cpburnem, memtestem oraz fsck. Hardware jest w porządku.

[tym 205]

Zbyt rygorystyczny grsec...

[qubaaa 0]

Zbyt rygorystyczny grsec...

Tak, ale gdyby tego nie logował, to dalej pozostaje problem zwiech. Serwer potrafi się zakrztusić 2 razy dziennie.

 

Serwer teraz przy normalnej pracy je jakies 700MB RAM, obciążenie rdzeni 50-60%. Nierzadko skacze na 100% i utrzymuje się na tym poziomie przez kilka sekund.

Edytowano Wrzesień 26, 2011 przez qubaaa (zobacz historię edycji)

[Gość patrys]

Z konfiguracja grsec by OVH były problemy, jeżeli chcesz korzystać z ich kerneli użyj takiego bez grsec.

Get: ftp://ftp.ovh.net/ma...age/2.6.38.2-2/

Do tego aktualizacja całego oprogramowania, jak się powtórzy napisz.

 

 

ps. przeniosłem temat.

[qubaaa 0]

Z konfiguracja grsec by OVH były problemy, jeżeli chcesz korzystać z ich kerneli użyj takiego bez grsec.

Get: ftp://ftp.ovh.net/ma...age/2.6.38.2-2/

Do tego aktualizacja całego oprogramowania, jak się powtórzy napisz.

 

 

ps. przeniosłem temat.

Zaktualizowałem kernela oraz całe oprogramowanie. Efektem jest brak segfaultów oraz szybsze działanie strony. Niestety problem zwiech nie zniknął. Jedyną rzeczą, jaką zaobserwowałem w logach podczas ziechy (jako zwiechy rozumiem bardzo duze czasy oczekiwania na reakcje serwera - zjada on wtedy 100% swapu i ramu) jest taki oto błąd:

[Mon Oct 03 10:10:21 2011] [error] server reached MaxClients setting, consider raising the MaxClients setting

[tym 205]

Zwiększ MaxClients w konfigu apacza i po problemie.

[qubaaa 0]

Zwiększ MaxClients w konfigu apacza i po problemie.

 

Na tyle także wpadłem. Chodzi mi jednak o kwestię zachowania serwera. Czy zamiast zżerać cały ram i swap, nie powinien on po prostu klientom ponad normę wyświetlać informacji, że strona nie może zostać wyświetlona?

[blackfire 185]

Na tyle także wpadłem. Chodzi mi jednak o kwestię zachowania serwera. Czy zamiast zżerać cały ram i swap, nie powinien on po prostu klientom ponad normę wyświetlać informacji, że strona nie może zostać wyświetlona?

 

Jeżeli tak skonfigurowałeś serwer że może zeżreć cały ram+swap, to to robi. *Zmniejsz* MaxClients bo widać że ustawiłeś za dużo jak na możliwości maszyny, postaw z przodu jakieś cache'ujące proxy typu varnish (skonfiguruj ładną 503kę przy przeciążeniu). Możesz też zastąpić apache'a nginxem/lightym/litespeedem (pomoże jeżeli większość treści to static, bo jeżeli 90% to odwołania dynamiczne to cudów nie ma, php_czy_co_tam swoje musi zeżreć).

 

Jeżeli to php to eacceleratora/apc/innego_cache_bajtkodu używasz?

[qubaaa 0]

Jeżeli tak skonfigurowałeś serwer że może zeżreć cały ram+swap, to to robi. *Zmniejsz* MaxClients bo widać że ustawiłeś za dużo jak na możliwości maszyny, postaw z przodu jakieś cache'ujące proxy typu varnish (skonfiguruj ładną 503kę przy przeciążeniu). Możesz też zastąpić apache'a nginxem/lightym/litespeedem (pomoże jeżeli większość treści to static, bo jeżeli 90% to odwołania dynamiczne to cudów nie ma, php_czy_co_tam swoje musi zeżreć).

 

Jeżeli to php to eacceleratora/apc/innego_cache_bajtkodu używasz?

Nie korzystam z cache'ującego proxy. Akceleratorem jest apc.

 

Pomyślę nad varnishem, gdy optymalizacja konfiguracji nie da efektów.

 

Po lekturze paru źródeł szczerze powiedziawszy mam wątpliwości czy żarcie swapu zostało spowodowane za dużą, czy za małą wartością maxclients. Błąd z error loga sugeruje, że jest to za mała liczba.

Maszyna o której mowa ma zaledwie 2GB RAMu. Biorąc pod uwagę fakt, że są to w 90% skrypty php, zakładam że na jeden poromny proces przypada 10 MB. Dzieląc ram przez tą liczbę mam lekko ponad 200. Przyjmując, że maszyna sama z siebie już trochę ramu zjada ze względu na inne odpalone procesy, ustawilem maxclients na 175. Poprzednia wartość wynosiła 150.

 

Obecna konfiguracja mpm workera:

<IfModule mpm_worker_module>
   	StartServers        	2
   	MinSpareThreads 		25
   	MaxSpareThreads 		75
   	ThreadsPerChild 		25
   	MaxClients                  	175
   	MaxRequestsPerChild 	10000
</IfModule>

Edytowano Październik 3, 2011 przez qubaaa (zobacz historię edycji)

[tym 205]

Polecam zmianę mpm na prefork. Zapewne cały serwer nadaje się do optymalizacji...

Edytowano Październik 3, 2011 przez Gość (zobacz historię edycji)

[malu 460]

Polecam zmianę mpm na prefork. Zapewne cały serwer nadaje się do optymalizacji...

 

Hm?

Jesteś pewien tego co polecasz, bo chyba nie za bardzo rozumiesz co polecasz.

[blackfire 185]

Pomyślę nad varnishem, gdy optymalizacja konfiguracji nie da efektów.

 

IMHO od tego zacznij bo może się okazać że varnish weźmie na klatę 90% ruchu i nie będzie po co optymalizować apache'a.

 

Po lekturze paru źródeł szczerze powiedziawszy mam wątpliwości czy żarcie swapu zostało spowodowane za dużą, czy za małą wartością maxclients. Błąd z error loga sugeruje, że jest to za mała liczba.

 

Jednocześnie za mała (względem liczby odwiedzających) i za duża (względem możliwości maszyny). Jakbyś się nie kręcił, dupa zawsze z tyłu.

 

Maszyna o której mowa ma zaledwie 2GB RAMu. Biorąc pod uwagę fakt, że są to w 90% skrypty php, zakładam że na jeden poromny proces przypada 10 MB. Dzieląc ram przez tą liczbę mam lekko ponad 200. Przyjmując, że maszyna sama z siebie już trochę ramu zjada ze względu na inne odpalone procesy, ustawilem maxclients na 175. Poprzednia wartość wynosiła 150.

 

No jedziesz po bandzie. Ledwie 200MB (w porywach) na page cache to proszenie się o OOM i zarżnięcie wydajności maszyny (co zdążyłeś już zauważyć).

 

Obecna konfiguracja mpm workera:

<IfModule mpm_worker_module>
   	StartServers        	2
   	MinSpareThreads 		25
   	MaxSpareThreads 		75
   	ThreadsPerChild 		25
   	MaxClients                  	175
   	MaxRequestsPerChild 	10000
</IfModule>

 

mpm_worker jest OK, zwłaszcza jak uruchomisz php po fastcgi (choć jak dla mnie to masz mało procesów a dużo wątków per proces). Jak uruchamiasz php, bo w wątkowanym mpmie mod_php AFAIK nie działa stabilnie? Inna sprawa że jak masz serwer pod tę jedną aplikację to poświęć parę godzin na konfigurację nginxa + fastcgi + php_fpm, na takiej maleńkiej maszynce powinieneś zobaczyć dużo więcej wolnej pamięci.

[Gość patrys]

poświęć parę godzin na konfigurację nginxa + fastcgi + php_fpm

To dobra podpowiedź i myślę że dał by to radę zrobić szybciej.

Jednak nie znając tego może mieć później problemy z np. standardowymi limitami i będzie musiał siedzieć przy logach i dokumentacji by to dostosować.

 

Worker faktycznie może nie być potrzebny na takiej maszynie, jeżeli jest jedna strona to przerzucić na preforka, dać php po mod_php plus xcache.

Potem w ramach optymalizacji coś ala varnish, czy memcached przy wykorzystywaniu mysql ale braknie pewnie ramu

[tym 205]

Hm?

Jesteś pewien tego co polecasz, bo chyba nie za bardzo rozumiesz co polecasz.

 

Rozumiem, co polecam, mpm prefork jest wydajniejszy i cechuje go mniejsze zużycie pamięci.

Jeśli jest to dla ciebie zbyt skomplikowane pojęcie, polecam google.

[blackfire 185]

Rozumiem, co polecam, mpm prefork jest wydajniejszy i cechuje go mniejsze zużycie pamięci.

Jeśli jest to dla ciebie zbyt skomplikowane pojęcie, polecam google.

 

To coś nowego. Jesteś w stanie jakoś tę tezę obronić (bez odsyłania do google)?

[tym 205]

To coś nowego. Jesteś w stanie jakoś tę tezę obronić (bez odsyłania do google)?

 

Jasne, aktualne zużycie pamięci przy preforku:

root@test:/# free -m
			total   	used   	free 	shared	buffers 	cached
Mem:   		512 		42    	469      	0      	0      	0
-/+ buffers/cache: 		42    	469
Swap:        	0      	0      	0

 

szybka zmiana na worker,

root@test:/# free -m
			total   	used   	free 	shared	buffers 	cached
Mem:   		512    	311    	200      	0      	0      	0
-/+ buffers/cache:    	311    	200
Swap:        	0      	0      	0

 

lista procesów:

root@test:/# ps aux
USER   	PID %CPU %MEM	VSZ   RSS TTY  	STAT START   TIME COMMAND
root 		1  0.2  0.1   2024   676 ?    	Ss   15:55   0:00 init [2]
root  	1279  0.0  0.2  33436  1364 ?    	Sl   15:55   0:00 /usr/sbin/rsyslogd -c4
root  	1321  0.0  0.1   2284   760 ?    	Ss   15:55   0:00 /usr/sbin/cron
root  	1327  0.0  0.1   5484   964 ?    	Ss   15:55   0:00 /usr/sbin/sshd
root  	1343  0.0  0.3   2972  1636 pts/0	Ss   15:56   0:00 -bash
root  	1464  0.0  0.5   5460  2640 ?    	Ss   15:56   0:00 /usr/sbin/apache2 -k start
www-data  1465  0.0  0.3   5232  1828 ?    	S	15:56   0:00 /usr/sbin/apache2 -k start
www-data  1466  0.0  0.4 282060  2276 ?    	Sl   15:56   0:00 /usr/sbin/apache2 -k start
root  	1536  0.0  0.1   2344   904 pts/0	R+   15:57   0:00 ps aux

 

Test przeprowadzony na serwerze z wirtualizacją OpenVZ.

 

@@edit

 

Przeprowadziłem również test dla wirtualizacji Xen-HVM. Wiadomo, że Xen lepiej zarządza pamięcią, dlatego też nie dziwie się że zużycie wygląda podobnie, zarówno dla prefork`a jak i worker`a:

 

prefork:

 

root@193:~# free -m
			total   	used   	free 	shared	buffers 	cached
Mem:   		248    	201 		47      	0 		89 		76
-/+ buffers/cache: 		35    	213
Swap:      	465      	3    	462

 

worker:

root@193:~# free -m
    		total   	used   	free 	shared	buffers 	cached
Mem:   		248    	203 		45      	0 		89 		76
-/+ buffers/cache: 		37    	211
Swap:      	465      	3    	46

 

Oczywiście serwery w standardowej konfiguracji, bez żadnej optymalizacji.

Edytowano Październik 3, 2011 przez tym (zobacz historię edycji)

[blackfire 185]

Jasne, aktualne zużycie pamięci przy preforku:

root@test:/# free -m
			total   	used   	free 	shared	buffers 	cached
Mem:   		512 		42    	469      	0      	0      	0
-/+ buffers/cache: 		42    	469
Swap:        	0      	0      	0

 

szybka zmiana na worker,

root@test:/# free -m
			total   	used   	free 	shared	buffers 	cached
Mem:   		512    	311    	200      	0      	0      	0
-/+ buffers/cache:    	311    	200
Swap:        	0      	0      	0

 

Aż z radości Cię zaplusowałem (jakiś mod mi to anuluje?) zamiast odpowiedzieć. Po pierwsze meminfo z openvz jak widzisz jest głównie humorystyczne (zero cache itd., bo tak ogólnie wyliczenie RSS dla kilku wybranych procesów nie jest całkowicie trywialne). Po drugie, nie podałeś konfiguracji obu mpmów (tak, też umiem skonfigurować preforka tak że zajmie mniej pamięci niż worker). Większość tej pamięci to jest (IIRC) scoreboard, którego wielkość (IIRC takoż, dawno we wnętrznościach apache'a nie grzebałem) zależy w zasadzie wyłącznie od MaxClients (a dokładnie to liczby procesów * liczby wątków).

 

Porównaj Pss z /proc/<pid>/smaps w obu MPMach na porównywalnej konfiguracji, myślę że nie zauważysz różnicy, o którą warto kruszyć kopie. To że worker zużywa więcej przestrzeni adresowej per proces to też nic specjalnie dziwnego ale nie przekłada się na zużycie pamięci fizycznej (jak masz domyślne bodajże 2MB na stos to na wstępie masz 2MB VM per wątek, z czego realnie wykorzystane będzie w porywach kilka 4KB stron).

 

Najbardziej debilne narzędzia rzeczywiście pokazują użycie VM zamiast RSS (vserver-stat np., z tego co widzę to /proc/meminfo z openvz też). Porównaj sobie na wyniku ps przydzieloną przestrzeń adresową (VSZ) z rzeczywiście użytą (RSS, choć właściwie PSS powinien być, ale tu błąd będzie porównywalny dla obu mpmów) -- te 200 MB nie znaczy absolutnie nic, istotne jest to oszałamiające 2MB z ogonkiem (z czego większość jest dzielona z parentem zajmującym <2MB ale ps tego nie pokaże).

 

awk '/^Pss: / { sum += $2 } END { print sum " KB" }' < /proc/PID/smaps

 

EDIT_za_edit:

Xen pokazał Ci prawdziwe zużycie pamięci fizycznej, czyli mniej więcej to, o czym pisałem powyżej. "Wiadomo, że Xen lepiej zarządza pamięcią" -- mocne

Edytowano Październik 3, 2011 przez blackfire (zobacz historię edycji)

[malu 460]

Rozumiem, co polecam, mpm prefork jest wydajniejszy i cechuje go mniejsze zużycie pamięci.

Jeśli jest to dla ciebie zbyt skomplikowane pojęcie, polecam google.

 

Pozwolę sobie, nawet nie ustosunkowywać się do Twojej radosnej twórczości jaką zaprezentowałeś powyżej. Bo cudnie zrobił to blackfire.

Zasadniczo, różnie można rozpatrzyć te Twoje wypowiedzi. Bo patrząc na to, że qubaaa używa interpretatora PHP z mpm-worker. Wiemy, że nie używa mod_php. A więc serwuje sobie PHP przy użyciu fcgi/cgi, dodatkowo może używa do tego jakiegoś wrappera. (suphp, suexec) W ten sposób sumarycznie zużywa więcej pamięci, aniżeli używałby mpm-prefork + mod_php, nawet gdyby dorzucił jakiś moduł korzystający z linuxowych capabilities np. mod_ruid2.

Więc w takim wypadku Twoja teza się zgadza, jeżeli chodzi o zużycie pamięci. Ale błagam, trochę precyzji, proszę też nie odsyłaj mnie do google, bo w internecie mnóstwo ścierwa można znaleźć. Jeżeli mówisz o czymś to przedstaw konkrety.

 

Ale jeżeli mówimy o samym wyborze MPM (Multi-Processing Module), nawet bez większego przemyślenia "how it works" to oczywistym jest to, że mpm-worker zużyje mniejszą ilość zasobów do serwera do serwerownia treści statycznej, aniżeli byłoby to w przypadku mpm-prefork przy identycznym ruchu. Nie trzeba wykazywać geniuszu, wystarczy przeczytać dokumentacje obydwu MPM, albo logicznie pomyśleć jaka filozofia działania będzie wydajniejsza i będzie zapewniać mniejsze zużycie zasobów serwera.

[Gość patrys]

Ale jeżeli mówimy o samym wyborze MPM (Multi-Processing Module), nawet bez większego przemyślenia "how it works" to oczywistym jest to, że mpm-worker zużyje mniejszą ilość zasobów do serwera do serwerownia treści statycznej, aniżeli byłoby to w przypadku mpm-prefork przy identycznym ruchu. Nie trzeba wykazywać geniuszu, wystarczy przeczytać dokumentacje obydwu MPM, albo logicznie pomyśleć jaka filozofia działania będzie wydajniejsza i będzie zapewniać mniejsze zużycie zasobów serwera.

Ciekawa sprawa, kolega wyżej ( nie czytałem dogłębnie wątku ) twierdzi chyba że ma problem z php, a nie statyką.

Statyki w ogóle nie powinno się serwować w środowiskach produkcyjnych na apache, bo notabene nie jest najwydajniejszy w tym.

Apache dobrze sobie radzi z php, statykę ładnie można rozdzielić przed nim i za serwować z odpowiedniego do tego zadania serwera www.

NIe znam większych problemów z wydajnością CPU/MEM dla wykonania php via mod_php.

[malu 460]

Ciekawa sprawa, kolega wyżej ( nie czytałem dogłębnie wątku ) twierdzi chyba że ma problem z php, a nie statyką.

Statyki w ogóle nie powinno się serwować w środowiskach produkcyjnych na apache, bo notabene nie jest najwydajniejszy w tym.

Apache dobrze sobie radzi z php, statykę ładnie można rozdzielić przed nim i za serwować z odpowiedniego do tego zadania serwera www.

NIe znam większych problemów z wydajnością CPU/MEM dla wykonania php via mod_php.

 

Jasne w stu procentach się z Tobą zgadzam.

Po prostu dyskusja zeszła trochę na bok, na kwestie MPM i też moja wypowiedź dotyczyła wyłącznie prefork vs worker. Przyznaję się do OT.

[qubaaa 0]

Istotnie bardzo ładnie zboczyliście z tematu, jednakże przynajmniej coś z tego mogłem wyciągnąć.

 

Weryfikuję wasze domysły: na serwerze mam prawie wyłącznie skrypty napisane w php, obsługujące bazę mysql.

Konfiguracja była bardzo standardowa - apache2 + mod_php + mysql.

 

Moja konkluzja tutaj jest taka, że zamiast żyłować tę maszynę, mogę ją zmienić na posiadającą 8GB DDR3 (obednie 2GB DDR2) w niemalże tej samej cenie. Mimo wszystko poczekam, bo póki co sytuacja się trochę ustabilizowała.

 

Gdyby ktoś miał jeszcze pomysł, co można tutaj poprawić, to chętnie wysłucham. Skoro konfiguracja nie różni się wiele od domyślnej, to wnioskuję, że można tutaj jeszcze coś poradzić.

 

Pozdrawiam i dziękuję za dotychczasową dyskusję.