php-fpm processz globális befagyás

Több php-fpm verziót is chrootban futtató környezetben néha (kb hetente egyszer) egy 5.6-os php-fpm szál befagy, és belassítja a teljes webes kiszolgálást akár az elérhetetlenségig. (Érdekes módon más php verziókét is!) A megoldás ilyenkor az 5.6-os fpm szerver újraindítása. A probléma határozottan egy felhasználóhoz köthető, valószínűleg a webgalamb starter.php programjához.

A kérdés azonban az, hogy egy php-fpm felhasználó hogyan tudhatja ennyire lefogni a kiszolgálást, mikor semmilyen erőforrást nem fogyaszt el. Memória, CPU, Disk, mind van szabadon. 8 magból 1-et köt le a kérdéses processz, bár azt tényleg 100%-osan. A php.ini max_execution_time értéke 60, mégis a processz addig fut, amíg a restart újra nem indítja a php szervert.

Az atop egyetlen érdekes értéke a SYSCPU és USRCPU értéke. Míg minden más processzel SYSCPU és USRCPU értéke 1s alatti, addig ennél a processzenél SYSCPU=38s, USRCPU=22s.

Találkozott már valaki hasonlóval?

Hogyan lehet a php-fpm-et úgy korlátozni, hogy egy kérelem kiszolgálása ne blokkolhassa a teljes környezetet. Például hogyan lehet elérni, hogy tényleg maximum 60s legyen a maximális futásidő?

Hozzászólások

> és belassítja a teljes webes kiszolgálást akár az elérhetetlenségig

Nem a webszervered fut ki ilyenkor a MaxClients-ből a sok várakozó kiszolgálási kérelem miatt?

Visszanéztem az atop logját, és valószínűleg nem. Az apache-ban 150 maximális kérelem van engedélyezve, de csak 3 apache processz fut végig 27 threaddel. Ennyi adatból úgy tűnik, a kérelmek nem halmozódnak fel. Ráadásul továbbra sem értem, hogy egy processz hogyan foghatná meg a többit.

Az strace lesz az új barátod :D

Mielőtt legközelebb restartolod, ereszd rá az 5.6-os php-fpm processzekre és nézd meg hogy mire várakozik

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

Szerkesztve: 2020. 05. 30., szo – 17:34

Pont leszarja a max_execution time-ot, én a leírt jelenségbe fpm-nél és cgi-nél is belefutottam. Valami memory leak vagy egyéb dolog, magában az fpm-ben, nem jöttem rá én sem. FPM-nél az lett a "megoldás", hogy beállítasz mondjuk egy pm.max_requests = 200 értéket, azaz az adott fpm process 200 kérés kiszolgálása után ki lesz nyírva, és indul helyette másik.

"Sose a gép a hülye."

Sajnos ez sem jött be, pedig még erősebb korlátokat állítottam:

emergency_restart_threshold = 3
emergency_restart_interval = 1m
process_control_timeout = 5
pm.max_requests = 50

valamint felemeltem a pm.max_children értékét.

Azóta már csak nagyon ritkán fordul elő. Érdekes módon csak olyan pool-ban, ahol a pm.max_children értéke 3 - gondolom, statisztikailag ezeknél állhat elő gyakrabban ez a helyzet.

Azt is kipróbáltam, hogy egy ilyen lefagyott php-fpm processz kiölése nem segít a dolgon, csak a teljes php 5.6-os verziójának újraindítása. Ha kiölöm a processz-t, egy következő lép a helyébe. Ha azt kilövöm, egy újabb.

Valamilyen - a php-k számára - globális erőforrás fogyhat el, mivel ilyenkor más php verziók is belassulnak néha, de az 5.6-os php újraindításával azok is ismét rendben mennek. Amúgy memória, disk, load teljesen normálisnak tűnik ezalatt is.