Konfigurera PHP-FPM: Använd pm static för maximal prestanda

Den oredigerade versionen av artikeln publicerades ursprungligen på haydenjames.io och publiceras här med tillstånd av dess författare.

Jag ska kort berätta hur man bäst konfigurerar PHP-FPM för att öka genomströmningen, minska latensen och mer stabilt använda CPU-resurser och minne. Som standard har PM (process manager, processhanterare) i PHP-FPM värdet dynamiskt, och om du har brist på minne är det bättre att ställa in ondemand. Låt oss jämföra två styralternativ baserat på dokumentationen från php.net och se vad som skiljer mitt favorit statisk pm för hög trafik:

pm = dynamiskt — antalet barnprocesser justeras dynamiskt baserat på följande direktiv: pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers.
pm = ondemand — processer skapas vid behov (till skillnad från dynamisk skapelse, där pm.start_servers startas vid boot av tjänsten).
pm = statisk — antalet barnprocesser är fast och anges med parametern pm.max_children.

Se detaljer i den fullständiga listan över globala direktiv i php-fpm.conf.

Likheterna mellan PHP-FPM:s processhanterare och CPU-frekvensregulatorn

Detta kan verka vara off-topic, men jag tänker koppla det till ämnet för PHP-FPM-konfigurationen. Har du någonsin upplevt att processorn har släpat sig — på en bärbar dator, virtuell maskin eller dedikerad server? Kommer du ihåg skalningen av CPU-frekvensen? Dessa alternativ, tillgängliga för nix och Windows, kan förbättra systemets prestanda och svarstid om CPU-regulatorparametern ändras från ondemand till prestanda*. Låt oss nu jämföra beskrivningarna och se likheterna:

Governor = ondemand — dynamisk skalning av CPU-frekvensen baserat på nuvarande belastning. Går snabbt upp på maxfrekvens och minskar den sedan när det blir längre perioder av inaktivitet.
Governor = konservativ = dynamisk skalning av frekvensen beroende på nuvarande belastning. Ökar och minskar frekvensen mjukare än ondemand.
Governor = prestanda — frekvensen är alltid maximal.

Se detaljer i den fullständiga listan över parametrar för CPU-frekvensregulatorn.

Ser du likheterna? Jag ville visa denna jämförelse för att övertyga dig om att det bästa alternativet är att använda pm statisk för PHP-FPM.

För CPU-regulatorn är parametern prestanda hjälper till att säkert öka prestandan, eftersom den nästan helt beror på serverns processorgräns. Dessutom finns det självklart andra faktorer som temperatur, batteriladdning (i bärbara datorer) och andra bieffekter av processorns konstant arbete på 100%. Inställningen av prestanda säkerställer den snabbaste processorn. Läs till exempel om parametern force_turbo i Raspberry Pi, där RPi-panelen kommer att använda reglaget prestanda, där prestandaförbättringen kommer att märkas mer på grund av den låga CPU-taktfrekvensen.

Användning av pm static för att uppnå maximal serverprestanda

PHP-FPM-parametern pm statisk beror mycket på det fria minnet på servern. Om minnet är ont är det bättre att välja ondemand eller dynamiskt. Å andra sidan, om du har minne, kan du undvika onödiga kostnader för PHP-processhanteraren genom att sätta pm statisk till serverns maximala kapacitet. Med andra ord, om allt beräknas noggrant, är det nödvändigt att ställa in pm.static till det maximala antalet PHP-FPM-processer som kan köras, utan att skapa problem med brist på minne eller cache. Men inte så högt att överbelasta processorerna och få en massa PHP-FPM-operationer som väntar på att utföras..

På skärmdumpen ovan är servern inställd på pm = static och pm.max_children = 100, och detta tar ungefär 10 GB av de 32 som finns. Observera de markerade kolumnerna, här är allt tydligt. På denna skärmdump var det ungefär 200 aktiva användare (mer än 60 sekunder) i Google Analytics. På denna nivå är ungefär 70% av PHP-FPM:s underprocesser fortfarande inaktiva. Det betyder att PHP-FPM alltid är inställd på att använda serverns maximala resurskapacitet oavsett nuvarande trafik. Den inaktiva processen väntar på trafiktoppar och reagerar omedelbart. Du behöver inte vänta på att pm skapar underprocesser, och sedan avslutar dem när perioden pm.process_idle_timeout. Jag har ställt in ett mycket stort värde för pm.max_requests, eftersom detta är en arbetsserver utan minnesläckor i PHP. Du kan ställa in pm.max_requests = 0 med static, om du är helt säker på de nuvarande och framtida PHP-skripten. Men det är bättre att starta om skripten med tiden. Sätt ett stort antal förfrågningar, eftersom vi vill undvika onödiga pm-kostnader. Till exempel minst pm.max_requests = 1000 — beroende på antalet pm.max_children och antal förfrågningar per sekund.

På skärmdumpen visas kommandot Linux top, filtrerat efter u (användare) och PHP-FPM-användarnamn. Visar bara de 50 första processerna (har inte räknat exakt), men i grund och botten visar top topstatistik som placeras i terminalfönstret. I det här fallet med sortering efter % CPU (%CPU). För att se alla 100 PHP-FPM-processer, utför kommandot:

top -bn1 | grep php-fpm

När man använder pm ondemand och dynamic

Om man använder pm dynamiskt, uppstår sådana fel:

WARNING: [pool xxxx] verkar vara upptagen (du kan behöva öka pm.start_servers, eller pm.min/max_spare_servers), skapar 32 barn, det finns 4 inaktiva, och 59 totalt barn

Försök att ändra parametern, felet kommer inte försvinna, som beskrivs i detta inlägg på Serverfault. I det här fallet var värdet på pm.min för litet, och eftersom web trafik varierar kraftigt med höga toppar och djupa dalar är det svårt att ställa in pm på ett korrekt sätt. dynamiskt. Oftast används pm ondemand, som rekommenderas i samma inlägg. Men det är ännu värre, eftersom ondemand det stänger inaktiva processer till noll när det är lite eller ingen trafik, och i slutänden kommer ni att få kämpa med kostnaderna vid trafikförändringar. Om ni inte har ställt in en lång väntetid. Och då är det bättre att använda pm.static + ett högt antal pm.max_requests.

PM dynamiskt och särskilt ondemand kan vara användbart om ni har flera PHP-FPM-pooler. Till exempel, om ni hostar flera cPanel-konton eller flera webbplatser i olika pooler. Jag har en server där, låt oss säga, 100+ cPanel-konton och cirka 200 domäner, och pm.static eller till och med dynamic skulle inte rädda mig. Här behövs bara ondemand, eftersom mer än två tredjedelar av webbplatserna får lite trafik eller ingen alls, och med ondemand kommer alla underprocesser att försvinna, vilket sparar massor av minne! Som tur är har utvecklarna av cPanel märkt detta och ställt in standardvärdet ondemand. Tidigare, när standardvärdet var dynamiskt, var PHP-FPM helt enkelt olämpligt för belastade delade servrar. Många använde suPHP, därför att pm dynamiskt använde minne även med inaktiva pooler och cPanel-konton av PHP-FPM. Troligtvis kommer ni, med bra trafik, inte att hosta på en server med ett stort antal PHP-FPM-pooler (delad hosting).

Slutsats

Om ni använder PHP-FPM och ni har seriös trafik, kommer processcheferna ondemand och dynamiskt för PHP-FPM att begränsa kapaciteten på grund av de inneboende kostnaderna. Undersök ert system och konfigurera PHP-FPM-processerna enligt serverns maximala kapacitet. Sätt först pm.max_children beroende på den maximala användningen av pm dynamiskt eller ondemand, och öka sedan detta värde till en nivå där minne och processor fungerar utan överbelastning. Du kommer att märka att pm statisk, eftersom allt lagras i minnet kommer trafiktoppar över tid att orsaka färre toppar för processorn, och genomsnittlig server- och processorbelastning kommer att jämnas ut. Den genomsnittliga storleken på PHP-FPM-processen beror på webbservern och kräver manuell justering, därför är mer automatiserade processhanterare dynamiskt och ondemand — mer populära. Jag hoppas att artikeln varit till hjälp.

UPD Benchmark-diagrammet har lagts till ab. Om PHP-FPM-processerna finns i minnet ökar prestandan på grund av minnesanvändning, där de sitter och väntar. Hitta det optimala alternativet för dig.

Källa: habr.com