[SOLVED] Apache hogy rohadna meg...

Fórumok

jó felütés, mi? de tényleg, rohadna meg. :)

szóval, egy rejtéllyel hadakozunk már lassan egy napja.

a kiszolgáló: fut rajta apache (php-s dinamikus oldalakat generálva), egy lighty (a statikus tartalomnak), mysql (memory és myisam táblákkal, az előbbiekben kizárólag és az utóbbiakban jobbára statikus oszlopformátummal, vagyis varchar-ok és text-ek nélkülözésével), memcached (bizonyos szerverszintű adatok tárolására). tehát mondhatni a szokásos webszerver, jó nagy látogatottsággal.

már eddig is csinálta néha, de új kódalap (több OOP -- de statikus classekkel; új SQL és memcache wrapper, stb) berakása után ez a tendencia nagyon felerősödött.

a kísérteties jelenség pedig: **ITT JÖN A LÉNYEG**

1. apache restart
2. minden pörög nagyon jól, a top-ban főleg httpd processzek, a load szépen kúszik fel
3. fogy a memóra (fogynia is kő hát)
4. még mindig pörög, load ugrál fel-le, memória is néha szabadul, néha nem
5. egy idő után egyre kevesebb a memóra (de nem mindig)
6. a top-ból kezdenek kiritkulni a httpd processzek
7. egyre nehezebben válaszol az oldal, a page load idő elkezd nőni erősen
8. elkezd zuhanni a load, egyre kevesebb httpd processz a topban
9. bejönnek a connect timeoutok, site unreachable, nem jött adat, stb
10. a load minimálisra esik, 10-20 httpd processz marad a topban, az oldal elérhetetlen

amiket megnéztem már:
- a memória NEM fogy el teljesen, a 8GB-ból kb. 300-400 mega megmarad
- amikor engedélyeztem az apache-nak a coredumpot, a belassulás közben és után sem coredumpolt, viszont apache leállítása (systemctl stop httpd.service) egy rakat ideig tartott, NA AKKOR kiírt egy raklapnyi dumpot. ki is kapcsoltam a dumpolást, legalább a restart legyen pörgős.
- játszadoztam egy sort a maxrequestsperchild-dal, hátha elfolyik a memória. 5000, 500, 50, végül dühömben 10. a különbség annyi volt, hogy minél kisebb, annál gyorsabban dőlt be a rendszer. na nem mindig, néha bírta. most épp 1.3GB ram van szabadon, és befulladt megint.
- próbáltam memcached és file alapú sessionökkel is (a file alapú is tmpfs-en van)

szóval... mi az ördög retkes valaga történik? a memória NEM fogy ki (teljesen), a load tolerálható mértéken belül van, egyszerűen az apache viselkedik úgy, hogy "köszi, fiúk, elég volt ez az öt perc munka, én most pihennék inkább", és ebből már csak az apache restart ébreszti fel.

gondoltam már arra is, hogy valamiért a session fájlokat lockolja, és belefut valami deadlockba egy idő után, de a kódátírás azt a részt nem érintette, meg már korábban is volt ilyen (csak nem ennyire jelentősen), mind memcached, mind fájl alapú sessionöknél.

valaki? help?

---

MEGOLDÁS: az egyik PHP scriptben egy nagyon jól elbújt végtelen ciklus volt, aztán a session file-ok lockolása miatt az egy idő után szépen beakasztotta az összes processzt. köszönöm mindenki segítségét, a strace innentől jó barátom lesz. :)

Hozzászólások

Bizti, hogy az apache eszi a memoriat/cpu-t?

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
--> YouTube csatornám

nem csak ő (a tmpfs meg a mysqld is, bőven), de mint mondtam, a legutóbbi kísérletnél, amikor már csak 10 rq/child-ot engedtem meg, 1.3GB szabad ram volt még a top szerint, amikor beállt a földbe ez a szar.

én is memóriaszivárgásra gyanakodtam mostanáig, de az alacsony maxrequestperchild lényege ugye elvileg az, hogy hiába folyik el a memória egy-egy processzben, mivel rohadt hamar lelövi és csinál helyette egy újat. de ez sem segített...

ja, és egy kis adalék: lslk alapján

...
httpd 30611 8,10 4602242 0 r 0 1 0 1 0 /tmp/.ZendSem.TsTEcx (deleted)
httpd 30620 8,10 4602242 0 r 0 1 0 1 0 /tmp/.ZendSem.TsTEcx (deleted)
httpd 30621 0,15 1444924022 3539 w 0 0 0 0 0 /var/lib/php/session/sess_mfgb4tv949lf7vrprm9mlcgis7
httpd 30621 8,10 4602242 0 r 0 1 0 1 0 /tmp/.ZendSem.TsTEcx (deleted)
httpd 30631 8,10 4602242 0 r 0 1 0 1 0 /tmp/.ZendSem.TsTEcx (deleted)
httpd 30636 8,10 4602242 0 r 0 1 0 1 0 /tmp/.ZendSem.TsTEcx (deleted)
httpd 30643 8,10 4602242 0 r 0 1 0 1 0 /tmp/.ZendSem.TsTEcx (deleted)
httpd 30651 8,10 4602242 0 r 0 1 0 1 0 /tmp/.ZendSem.TsTEcx (deleted)
httpd 30652 8,10 4602242 0 r 0 1 0 1 0 /tmp/.ZendSem.TsTEcx (deleted)
httpd 30663 8,10 4602242 0 r 0 1 0 1 0 /tmp/.ZendSem.TsTEcx (deleted)
...

WTF ez a /tmp/.ZendSem.TsTEcx, ami ráadásul deleted is? a google egy kanyi találatot sem ad rá. a varlibphpsession-ös lockokat még megértem, de ez...?

leírtad a hibajelenséget, de semmiféle infót arról hogy mi a helyzet.
1. Milyen szerver, mennyi memória(ezt éppen leírtad)
2. Mekkora látogatottságú oldal (rps)
3. db backend azonos gépen van-e, vagy remote, ha azonos, micsoda, ha nem, mekkora a latency
4. milyen fs
5. milyen verziók
6. milyen beállításokkal fut az apache/php/etc.

// Happy debugging, suckers
#define true (rand() > 10)

1. linux (fed17, hamarosan centos 6.5), 5.4.17-es php, 2.2.23-as apache, 8GB ram.
2. passz. pontos adat nincs, mivel loggolást sem tudok csinálni, annyira pörög. a lényeg, hogy maxclients 180-200 körül kiszolgálja úgy, hogy nincs tudomásunk rejected conn-ról (backlog 511-en max).
3. igen, mysqld.
4. ext3
5. ld fent.
6. SS 100, MxSS 100, MnSS 20, MS 180, MC 180, MRPC ki volt próbálva 10, 50, 500, 5000. most épp 10000-el fut, hogy rohadna meg. php standard beállítások. mysql szénné optimalizálva (jó nagy key cache, query cache, stb).

de nem ez a lényeg. hanem hogy eddig futott, és csak néha produkálta ezt. most pedig sűrűn. oké, egy fokkal nehezebb php-t kell futtatnia, na de ez a földbe állás azért valahogy mégsem klappol. mert mint mondom, a jelenség az, hogy egy idő után (5-10-20 perc) belassul, és nem kezd válaszolni. pedig memória van, a load pedig épp hogy leesik.

Próbáld meg, hogy az összes apache logot kikukázod.
Nekem volt régebben olyan problémám apache-al, valami a logban kiakasztotta. Pörgött felfele ahogy nálad, elhullottak a processek, majd mikor 15-20 fölé ment a load is, akkor már ssh-t is kivágta...

--
Fontos! Ha berágok, nem feltétlen személyed ellen szól...
openSUSE 13.1 x86_64

En azt neznem meg, hogy mit csinal akkor az apache, amikor behal (ha mas nem, strace). Igy ranezesre csak bokodtel ide-oda, hatha talal:)
Tippre olyan, mintha varna vmire, pl. sql vagy diszk vagy mas resource. A keepalive-ot kapcsold ki v. vedd vissza es nezd meg ugy.

udv,
tamas

na, ez a strace nem volt egy rossz ötlet:

...
nanosleep({0, 1000}, NULL) = 0
poll([{fd=15, events=POLLIN|POLLPRI}], 1, 0) = 0 (Timeout)
write(15, "4\0\0\0\3SELECT `TID` FROM `EP_galer"..., 56) = 56
read(15, "\1\0\0\1\1=\0\0\2\3def\reropolis_utf8\nEP_g"..., 16384) = 88
nanosleep({0, 1000}, NULL) = 0
poll([{fd=15, events=POLLIN|POLLPRI}], 1, 0) = 0 (Timeout)
write(15, "4\0\0\0\3SELECT `TID` FROM `EP_galer"..., 56) = 56
read(15, "\1\0\0\1\1=\0\0\2\3def\reropolis_utf8\nEP_g"..., 16384) = 88
nanosleep({0, 1000}, NULL) = 0
poll([{fd=15, events=POLLIN|POLLPRI}], 1, 0) = 0 (Timeout)
write(15, "4\0\0\0\3SELECT `TID` FROM `EP_galer"..., 56) = 56
read(15, "\1\0\0\1\1=\0\0\2\3def\reropolis_utf8\nEP_g"..., 16384) = 88
nanosleep({0, 1000}, NULL) = 0
...

és ez így megy, amíg világ a világ. illetve nem, mert előbb lecsapom.

szóval ez így nekem valami SQL kérésnek tűnik, méghozzá legit is a dolog, tudok erről a tábláról. de ennél többet nem értek az strace-ből, egy SQL kérés lefutására vár?

van viszont más is. amit írtam már fent, hogy furcsa lockfile-okat látok lslk-val.

példa:
...
httpd 30737 8,10 4602242 0 r 0 1 0 1 0 /tmp/.ZendSem.TsTEcx (deleted)
httpd 30738 8,10 4602242 0 r 0 1 0 1 0 /tmp/.ZendSem.TsTEcx (deleted)
httpd 30739 8,10 4602242 0 r 0 1 0 1 0 /tmp/.ZendSem.TsTEcx (deleted)
httpd 30740 8,10 4602242 0 r 0 1 0 1 0 /tmp/.ZendSem.TsTEcx (deleted)
httpd 30741 8,10 4602242 0 r 0 1 0 1 0 /tmp/.ZendSem.TsTEcx (deleted)
httpd 30742 8,10 4602242 0 r 0 1 0 1 0 /tmp/.ZendSem.TsTEcx (deleted)
httpd 30744 8,10 4602242 0 r 0 1 0 1 0 /tmp/.ZendSem.TsTEcx (deleted)
httpd 30746 8,10 4602242 0 r 0 1 0 1 0 /tmp/.ZendSem.TsTEcx (deleted)
httpd 30747 8,10 4602242 0 r 0 1 0 1 0 /tmp/.ZendSem.TsTEcx (deleted)
httpd 30748 8,10 4602242 0 r 0 1 0 1 0 /tmp/.ZendSem.TsTEcx (deleted)
httpd 30752 8,10 4602242 0 r 0 1 0 1 0 /tmp/.ZendSem.TsTEcx (deleted)
httpd 30753 8,10 4602242 0 r 0 1 0 1 0 /tmp/.ZendSem.TsTEcx (deleted)
httpd 30754 8,10 4602242 0 r 0 1 0 1 0 /tmp/.ZendSem.TsTEcx (deleted)
httpd 30760 8,10 4602242 0 r 0 1 0 1 0 /tmp/.ZendSem.TsTEcx (deleted)
httpd 30762 8,10 4602242 0 r 0 1 0 1 0 /tmp/.ZendSem.TsTEcx (deleted)
httpd 30763 8,10 4602242 0 r 0 1 0 1 0 /tmp/.ZendSem.TsTEcx (deleted)
httpd 30764 8,10 4602242 0 r 0 1 0 1 0 /tmp/.ZendSem.TsTEcx (deleted)
httpd 30765 8,10 4602242 0 r 0 1 0 1 0 /tmp/.ZendSem.TsTEcx (deleted)
...

a TsTEcx véletlen string, minden indulás után más.

amikor még ment a rendszer, kevesebb volt, de egyre több lett belőle. végül lelőttem a szervert, el is tűntek. ami a nagyon gyanús:
- indítás után hullámzik a .ZendSem lockok száma, néha teljesen el is tűnnek, és mindig más PIDhez vannak rendelve.
- de idővel elkezd egyre több lenni.
- a legutóbbi behalás után mennyi volt belőlük? BIZONY, 180, ami MEGEGYEZIK A MAXCLIENTS/MAXSERVERS JELENLEGI BEÁLLÍTÁSÁVAL.

mondoméén, hogy ez valami lockfile probléma lesz...

a forrása az opcache (http://gcov.php.net/PHP_HEAD/lcov_html/ext/opcache/zend_shared_alloc.c…) kódjában van.

na, ez annyira nem gáz, megtaláltam az -y switchet a strace-nél, a session file-t akarta lockolni, amit jó eséllyel már egy végtelen ciklusos cucc lockolt egy másik processzben.

köszi mindenkinek a segítséget, ez a strace jól jött most nagyon. ki gondolta volna, hogy az új kódbázisba befigyel egy végtelen ciklus lehetőség... pffft. így változtasson az ember method signature-t.

de elvileg a php nem futhat bele vegtelen ciklusba van egy ido keret ha azt tullepi a script lelovi compiler, persze fastcgi-ben lehet hosszabb az ido, de akkor is kihanya a browserbe hogy script time out. akkor is kivagja a compiler ha sql-ra var, ezzel elvileg nem lehet az apache-ot legyilkoni. Ha meg SQL-re varna akkor meg a mysql-lal szaladna el a lo. Volt mar olyan hogy rosszul zarojelezett or es and olyan szepen megakaszotta a mysql-t orom volt nezni. de a php time out es kalap meg a bot. haviszont a php akad meg akkor probalni kellen egy upgrade-t lehet maga php-ben van a hiba es nem a script-ben.

Sziasztok!

Hasonlóba belefutottam én is a napokban, az általad leírt jelenség teljes mértékben, egyszer csak nagyon lelassult a weboldalak kiszolgálása. Sajnos server-statust nem néztem, simán restart megoldotta. Log fileokat átnéztem, semmi különleges nem volt bennük.
Mindenesetre érdekes a dolog, lehet, hogy valami scanner öli meg az apache-ot?

-----
“Firefox, you say? No I don't play Pokémon”

Én belefutottam pár hete egy hasonló szituba. Kiderült, hogy sikerült egy get flood ba beleszaladnom. a mod_proxy disabled, szigoritottam a mod_secutrytin. kicsit modositottam a fw-t és a probléma megoldva. Detto ugyan ez volt a szitu, pár percig ment elkezdett lelassulni (ekkor elszabadult a pokol apache proceszek szamat tekintve) majd csendben meghalt -már mint a apache futott, de oldal nem jött be 1 bytenyi se. persze a memória az egekben.
apache restart megint elment vagy 5-10 percig ugyan ez.
nekem a log-ban bukott ki hogy mi a retek ez a rengeteg GET
http://ad.yahoo.com?xxxx eddig használva volt a mod_proxy egyetetlen egy külső átírányítás miatt egy site-on, de meg lett oldva a http headerrel.

nekem elsõre hálózati issue-nak tũnik. nézted a tcp socketek számát?

"statikus oszlopformátum" nem fixed oszlopszelesség akar lenni?

~~~~~~~~
deb http://deb.metaltux.tk/ wheezy testing

Reggelt,

mondjuk a legszebb a topic neve.

Erre mondjak, hogy azert mert nem tudsz bevenni egy kanyart, meg nem a kocsi a hibas :)