Rejtélyes Apache elhalálozás

Linux-haladó

Légyszi segítsetek, mert már kezdek kifogyni a gondolatokból.

Adott egy debian webszerver (virtuális, xen), rajta apache2, php5, perl. Időnként, gondol egyet és nem jönnek be az oldalak, helyettük bejön a PHP által adott hibaüzenet, hogy: out of memory meg PHP Fatal error: Out of memory. A top-ban van szabad memória, van szabad swap hely.

Az apache error logokban a következő hibák vannak:

[error] [client x.x.x.x] unable to init Zlib: deflateInit2 returned -4: URL /index.php
[notice] child pid 19154 exit signal Segmentation fault (11)
[error] (12)Cannot allocate memory: fork: Unable to fork new process

Amiket próbáltam:
sysctl beállítások
vm.overcommit_memory = 2
vm.overcommit_ratio = 80

apache-ban módosítottam a prefork beállításokon

StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxClients 150
MaxRequestsPerChild 500

és php-ben megemeltem a lefoglalható memória méretét
memory_limit = 128M

Időnként - de nem minden esetben a dmesg-ben is vannak hibák:
[1524977.054593] apache_volume[29586]: segfault at 20 ip 00007f803096fee2 sp 00007fff49e625f0 error 4 in libperl.so.5.10.1[7f8030930000+165000]

ii php5 5.3.3-7+squeeze3
ii libapache2-mod-perl2 2.0.4-7
ii libapache2-mod-php5 5.3.3-7+squeeze3
ii libapache2-reload-perl 0.10-2
ii perl 5.10.1-17squeeze2

ls /etc/apache2/mods-enabled/
alias.conf authz_groupfile.load cgi.load env.load negotiation.conf reqtimeout.conf ssl.conf userdir.load
alias.load authz_host.load deflate.conf expires.load negotiation.load reqtimeout.load ssl.load vhost_alias.load
auth_basic.load authz_user.load deflate.load headers.load perl.load rewrite.load status.conf
authn_file.load autoindex.conf dir.conf mime.conf php5.conf setenvif.conf status.load
authz_default.load autoindex.load dir.load mime.load php5.load setenvif.load userdir.conf

Help pliiiz.
Köszi!

  • 4264 megtekintés

( Croc | 2012. 01. 18., sze – 15:31 )

php.ini -ben nézd meg a php által használható memória értékét.
Talán max_memory a paraméter, de épp nincs elöttem olyan gép amin meg tudnám nézni.
Állítsd nagyobbra, és máris jobb lesz (egy ideig) :)
Persze után apache reload/restart izlés szerint.

Szerk: Bocs, láttam, ezzel már próbálkoztál.

Nézd meg, hogy lehetösége van-e a rendszernek további szálakat indítani. A fork talán ilyesmire utalhat.

( Croc | 2012. 01. 18., sze – 15:40 )

Egyébként mennyi Ram járt a virtuális gépedhez? Nem lehet, hogy hosszú távon tényleg kifogy belölle a gép? A top-ban ilyenkor mit látsz? Nincs megnövekedett swap használat ilyenkor?

A topban azt látom, hogy van még szabad fizikai memória is, meg swap is. Nem tűnik többnek a használt swap, de majd figyelem.
A memória asszem 2G, de tudom emelni, a host gépet is én csináltam. A gondom az, hogy szerintem ennyinek elégnek kéne lennie... Dec. óta van ez a gond, mindenki váltig állítja, hogy nem nyúltak semmihez. Se a weboldalakon nem fejlesztettek, se a szerveren nem matattak.

--
TH

Más választás hirtelen nincs, emeld még feljebb a php.ini-ben a RAM-ot.
Egyébként ha jól emlékszem valahol írja is, hogy "ennyi-meg ennyi" kellett volna még neki... ez esetleg segíthet a megfelelö érték beállításához.

Illetve valahogy meg lehet azt is nézni, ha más nem a kód módosításával, hogy mennyi memóriára lenne szüksége annak a müveletnek az elvégzéséhez, aminél kihal. Elöször persze meg kell találni valahogy azt a funkciót/kódrészletet.
Sajnos nem megy másképp...

Ha egyik sem segít, akkor próbálj up/downgradelni, hátha esetleg bug...

szerintem azért tolj egy find-ot és nézd meg, hogy nincs-e olyan fájl, aminek az utolsó változtatási ideje egybeesik a problémák kezdödésével. Ugyan az ügyfél mindig váltig állítja, hogy nem csinált semmit, még is néha elöfordul, hogy elfelejtik, mit csináltak. Annyira ismerös a szitu.....

szerk: jah, és kell nekik a perl modul egyáltalán, ha csak php-t használnak?

( ang | 2012. 01. 18., sze – 16:38 )

/etc/security/limits.conf -t ellenorizd

csunya hack-kent ulimit -u unlimited az initscriptbe

( th v | 2012. 01. 18., sze – 17:25 )

Alap beállítások vannak, tulképp üres... Jó ez így nekem?
--
TH

( Sea-you | 2012. 01. 18., sze – 17:52 )

Probalkozz meg a deflate kikapcsolasaval ha be van konfiguralva. A hibauzenet alapjan en ezt probalnam meg eloszor.

( Sea-you | 2012. 01. 20., p – 08:57 )

Ugyanezt a hibat irta ki a deflate kikapcsolasa utan is? Mert akkor nem sikerult kikapcsolni ezekszerint.

A mod_deflate arra valo, hogy tomoritse a halozaton atkuldendo adatokat, amit aztan a bongeszo kicsomagol, igy kisebb savon lehet attolni tobb adataot, persze cserebe proci es memoriaigenyes (inkabb proci).

Igy tudod kikapcsolni:

# kikapcsolas olyan urlekre amik foo/bar/-ral kezdodnek
SetEnvIf Request_URI ^/foo/bar/ no-gzip=1

# kikapcsolas fileokra amik .php kiterjesztesuek

SetEnv no-gzip 1

( zwei | 2012. 01. 20., p – 10:43 )

Ha perlt is futtatsz, akkor lehet, hogy egy hibás perl cgi felfalja a memóriát, aztán amikor megdöglik az apache a memória megint felszabadul, és azért látod, hogy van elég szabad.

A perl cgi álltal felhasználható max memóriát kéne limitálni valahogy (fastcgi?)

Próbáltam az mpm prefork + mod_php párost lecserélni worker + fcgire. Részben működött is, de voltak oldalak, ahol a \n karakterek helyett n betű jelent meg, vagy rossz karakterkódolással jöttek az eredmények, illetve az ajaxban írt lekérdezések nem futottak le. Sajnos nem volt elég időm a memóriás hibák tesztelésére ezek mellett a problémák mellett. Viszont, mintha nem láttam volna a workeres felállásnál segfaultos problémákat.

Igazából nincs szükség arra, hogy több user futtathasson php-t, szóval ez csak teszt volt.

--
TH

( th v | 2012. 02. 03., p – 22:08 )

Sajnos nemigen jutok előbbre a problémával :( Megpróbáltam áttenni egy másik vasra a VM-et, de ott is ugyan ezt a hibajelenséget produkálta (még viszonylag nyugis időben is. Most épp egy tesztszervert gyártok, megpróbálom egy szűz apache+php konfiggal a fontosabb oldalakat. Szerintetek hogy tudok minél nagyobb terhelést generálni a tesztgépen?

--
TH

( th v | 2012. 02. 10., p – 09:08 )

Végre eikerült eredményeket elérnem.
Találtam egy oldalt (http://www.devside.net/articles/apache-performance-tuning), ahol apache finombeállításokról volt szó, annak alapján tekergettem rajta.
Levettem a timeoutokat, kikapcsoltam a keepaliveot, átállítottam a preforkot.

Timeout 60
KeepAlive Off
MaxKeepAliveRequests 100
KeepAliveTimeout 5

StartServers 8
MinSpareServers 5
MaxSpareServers 20
MaxClients 100
ServerLimit 256
MaxRequestsPerChild 1000

A mod_status configban letiltottam az ExtendedStatust.
A php konfigjában visszább vettem a foglalható memóriát (memory_limit).

Az egyik site .htaccess filejában korlátozni kellett a rewrite beállításokat (egyébként szerintem ez okozta az egész galiba alapját).

RewriteCond %{ENV:REDIRECT_STATUS} 100
RewriteRule .* - [L]

Lekopogom, de 2 napja nem volt komolyabb hibaüzenet és az "unable to fork..." hibákból egyet sem láttam.
Remélem megtartja a jó szokását és rendesen viselkedik ezek után :)
--
TH