En oredigerad version av denna artikel publicerades ursprungligen på och publiceras här med hennes tillstånd .
Jag ska gå igenom i ett nötskal det bästa sättet att konfigurera PHP-FPM för att öka genomströmningen, minska latens och använda CPU och minne mer konsekvent. Som standard är PM-raden (processhanteraren) i PHP-FPM dynamisk, och om du inte har tillräckligt med minne är det bättre att installera ondemand. Låt oss jämföra 2 kontrollalternativ baserat på php.net-dokumentationen och se hur min favorit skiljer sig från dem statisk pm för trafik med hög volym:
pm = dynamisk — antalet underordnade processer konfigureras dynamiskt baserat på följande direktiv: pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers.
pm = på begäran - processer skapas på begäran (till skillnad från dynamiskt skapande, när pm.start_servers startas när tjänsten startar).
pm = statisk — Antalet underordnade processer är fast och indikeras av parametern pm.max_barn.
För detaljer, se .
Likheter mellan PHP-FPM process manager och CPU frekvenskontroller
Detta kan verka offtopic, men jag kommer att länka detta till ämnet PHP-FPM-konfiguration. Vem har inte upplevt en processornedgång minst en gång - på en bärbar dator, virtuell maskin eller dedikerad server. Kommer du ihåg CPU-frekvensskalning? Dessa alternativ är tillgängliga för nix och Windows kan förbättra systemets prestanda och lyhördhet genom att ändra processorns gasinställning från ondemand på prestanda*. Den här gången ska vi jämföra beskrivningarna och titta på likheterna:
guvernör=begäran — dynamisk skalning av processorfrekvens beroende på aktuell belastning. Hoppar snabbt till maximal frekvens och minskar den sedan när perioder av inaktivitet ökar.
guvernör=konservativ= dynamisk frekvensskalning beroende på aktuell belastning. Ökar och minskar frekvensen smidigare än på begäran.
Guvernör = prestation — frekvensen är alltid maximal.
För detaljer, se .
Ser du likheterna? Jag ville visa den här jämförelsen för att övertyga dig om att den är bäst att använda pm statisk för PHP-FPM.
För parametern processorregulator prestanda hjälper till att på ett säkert sätt öka prestandan eftersom det nästan helt är beroende av serverns CPU-gräns. Utöver detta finns det förstås även faktorer som temperatur, batteriladdning (i en bärbar dator) och andra bieffekter av att hela tiden köra processorn på 100%. Prestandainställningen säkerställer den snabbaste processorprestandan. Läs till exempel om , med vilken RPi-panelen kommer att använda regulatorn prestanda, där prestandaförbättringen kommer att märkas mer på grund av den låga CPU-klockhastigheten.
Använder pm static för att uppnå maximal serverprestanda
PHP-FPM-alternativ pm statisk beror till stor del på det lediga minnet på servern. Om minnet är lågt är det bättre att välja ondemand eller dynamisk. Å andra sidan, om du har minne kan du undvika PHP-processhanterarens overhead genom att ställa in pm statisk till maximal serverkapacitet. Med andra ord, om allt är välkalkylerat måste du fastställa pm.statisk till den maximala volymen av PHP-FPM-processer som kan köras, utan att skapa problem med lågt minne eller cache. Men inte så högt att det överväldigar processorerna och samlar på sig ett gäng PHP-FPM-operationer som väntar på att exekveras.
I skärmdumpen ovan har servern pm = statisk och pm.max_children = 100, och detta tar upp ungefär 10 GB av de tillgängliga 32. Var uppmärksam på de markerade kolumnerna, allt är klart här. I den här skärmdumpen fanns cirka 200 aktiva användare (mer än 60 sekunder) i Google Analytics. På denna nivå är ungefär 70 % av PHP-FPM underordnade processer fortfarande inaktiva. Detta innebär att PHP-FPM alltid är inställt på den maximala mängden serverresurser oavsett aktuell trafik. En inaktiv process väntar på trafiktoppar och svarar omedelbart. Du behöver inte vänta tills pm kommer att skapa underordnade processer och sedan avsluta dem när perioden löper ut pm.process_idle_timeout. Jag satte värdet till mycket högt pm.max_requestseftersom detta är en fungerande server utan minnesläckor i PHP. Du kan installera pm.max_requests = 0 med statisk om du är helt säker på befintliga och framtida PHP-skript. Men det är bättre att köra om skripten med tiden. Ställ in ett stort antal förfrågningar, eftersom vi vill undvika onödiga pm-kostnader. Till exempel åtminstone pm.max_requests = 1000 - beroende på kvantitet pm.max_barn och antalet förfrågningar per sekund.
Skärmdumpen visar kommandot , filtrerad av u (användare) och PHP-FPM användarnamn. Endast de första 50 eller så processer visas (jag räknade inte exakt), men i huvudsak visar toppstatistiken som passar in i terminalfönstret. I detta fall sorterat efter % CPU (%CPU). För att se alla 100 PHP-FPM-processer, kör kommandot:
top -bn1 | grep php-fpmNär ska man använda pm ondemand och dynamisk
Om du använder pm dynamisk, fel som detta inträffar:
WARNING: [pool xxxx] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 32 children, there are 4 idle, and 59 total childrenFörsök att ändra parametern, felet kommer inte att försvinna, typ . I det här fallet var värdet för pm.min för litet, och eftersom webbtrafiken varierar så mycket och har höga toppar och djupa dalar är det svårt att justera pm tillräckligt dynamisk. Vanligtvis används pm ondemand, . Men det här är ännu värre, eftersom ondemand avslutar inaktiva processer till noll när det finns liten eller ingen trafik, och du kommer fortfarande att sluta med omkostnaderna för att ändra trafik. Såvida du inte ställer in en enorm väntetid förstås. Och då är det bättre att använda pm.statisk + högt antal pm.max_requests.
PM dynamisk och speciellt ondemand kan vara praktiskt om du har flera PHP-FPM-pooler. Till exempel är du värd för flera cPanel-konton eller flera webbplatser i olika pooler. Jag har en server med, säg, 100+ cpanel-konton och cirka 200 domäner, och pm.static eller till och med dynamisk skulle inte rädda mig. Allt du behöver här är ondemand, trots allt får mer än två tredjedelar av webbplatserna liten eller ingen trafik, och med ondemand alla barnprocesser kommer att falla av, vilket kommer att spara oss mycket minne! Lyckligtvis märkte cPanel-utvecklarna detta och satte värdet till standard ondemand. Tidigare, när standard var dynamisk, PHP-FPM var inte lämpligt för upptagna delade servrar alls. Många har använt suPHP, eftersom kl dynamisk förbrukat minne även med lediga pooler och cPanel PHP-FPM-konton. Troligtvis, om trafiken är bra, kommer du inte att vara värd på en server med ett stort antal PHP-FPM-pooler (delad hosting).
Slutsats
Om du använder PHP-FPM och din trafik är tung, processhanterare ondemand и dynamisk för PHP-FPM kommer att vara begränsad genomströmning på grund av deras inneboende overhead. Förstå ditt system och konfigurera PHP-FPM-processer enligt den maximala serverkapaciteten. Första set pm.max_barn beroende på maximal pm-användning dynamisk eller ondemand, och öka sedan detta värde till en nivå där minnet och processorn fungerar utan att överbelastas. Det kommer du att märka med pm statisk, eftersom du har allt i minnet, kommer trafikspikar att orsaka färre CPU-spikar över tiden, och server- och CPU-belastningsgenomsnitt kommer att plana ut. Den genomsnittliga PHP-FPM-processstorleken beror på webbservern och kräver manuell konfiguration, så mer automatiserade processhanterare är dynamisk и ondemand - mer populär. Jag hoppas att artikeln var användbar.
UPD Lade till benchmark-diagram . Om PHP-FPM-processer finns i minnet ökar prestandan på bekostnad av minnesförbrukningen där de sitter och väntar. Hitta det bästa alternativet för dig själv.
Källa: will.com