Нередактирана версия на статията е публикувана първоначално на и се публикува тук с разрешение на .
Ще споделя накратко как най-добре да настроите PHP-FPM, за да увеличите производителността, да намалите латентността и по-стабилно да използвате процесорните ресурси и паметта. По подразбиране редът PM (мениджър на процеси) в PHP-FPM има стойност dynamic, а ако имате недостиг на памет, по-добре е да зададете ondemand. Нека сравним 2 варианта за управление на базата на документацията на php.net и да видим какво ги отличава от моя любим static pm за голям обем трафик:
pm = dynamic — броят на дъщерните процеси се настройва динамично на базата на следните директиви: pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers.
pm = ondemand — процесите се създават при поискване (в противовес на динамичното създаване, когато pm.start_servers се стартират при стартиране на услугата).
pm = static — броят на дъщерните процеси е фиксиран и се задава с параметъра pm.max_children.
Повече подробности вижте в .
Сходства на мениджъра на процеси PHP-FPM с регулатора на честотата на процесора
Може да изглежда извън темата, но ще свържа това с настройките на PHP-FPM. На всеки поне веднъж не се е забавял процесорът — на лаптоп, виртуална машина или специален сървър. Помните ли мащабирането на честотата на процесора? Тези параметри, налични за nix и Windows, могат да повишат производителността и скоростта на отговор на системата, ако промените параметъра на регулатора на процесора на ondemand на performance*. Този път нека сравним описанията и разгледаме сходствата:
Governor = ondemand — динамично мащабиране на честотата на процесора в зависимост от текущото натоварване. Рязко преминава на максималната честота и след това я намалява, когато периодите на бездействие се увеличават.
Governor = conservative = динамично мащабиране на честотата в зависимост от текущото натоварване. Увеличава и намалява честотата по-гладко от ondemand.
Governor = performance — честотата винаги е максимална.
Повече подробности вижте в .
Виждате ли сходството? Исках да покажа това сравнение, за да ви убедя, че е най-добре да използвате pm static за PHP-FPM.
За регулатора на процесора параметърът performance помага за безопасното увеличаване на производителността, тъй като тя почти изцяло зависи от лимита на процесора на сървъра. Освен това, разбира се, има и други фактори, като температура, заряд на батерията (в лаптопа) и други странични ефекти от постоянната работа на процесора на 100%. Настройките за производителност осигуряват най-бързата работа на процесора. Например, прочетете за , с който панелът RPi ще използва контролера performance, където подобрението на производителността ще бъде по-очевидно поради ниската тактова честота на ЦП.
Използването на pm static за постигане на максимална производителност на сървера
Параметърът PHP-FPM pm static в значителна степен зависи от наличната памет на сървера. Ако паметта е малко, по-добре е да изберете ondemand или dynamic. От друга страна, ако разполагате с памет, можете да избегнете излишните разходи на процесния мениджър PHP, задавайки pm static на максималната капацитет на сървера. С други думи, ако всичко е добре изчислено, трябва да зададете pm.static на максималния брой PHP-FPM процеси, които могат да се изпълняват, без да създават проблеми с недостиг на памет или кеш. Но не толкова високо, за да не натоварите процесорите и да не натрупате куп операции PHP-FPM, чакащи за изпълнение..
На скрийншота по-горе сървърът е конфигуриран с pm = static и pm.max_children = 100, и това заема около 10 GB от наличните 32. Обърнете внимание на маркираните колони, тук всичко е ясно. На този скрийншот имаше около 200 активни потребители (повече от 60 секунди) в Google Analytics. На това ниво около 70% от дъщерните процеси PHP-FPM все още са бездействали. Това означава, че PHP-FPM винаги се настройва на максимален обем ресурси на сървера независимо от текущия трафик. Процесът в очакване чака пиковете на трафика и реагира мигновено. Не трябва да чакате, докато pm създаде дъщерни процеси, а след това да ги прекрати, когато изтече периодът pm.process_idle_timeout. Зададох много голямо значение за pm.max_requests, защото това е работещ сървър без течове на памет в PHP. Можете да зададете pm.max_requests = 0 с pm static, ако сте напълно уверени в наличните и бъдещите PHP скриптове. Но е по-добре да рестартирате скриптовете с времето. Задайте висока стойност на заявките, тъй като искаме да избегнем излишните разходи за pm. Например, поне pm.max_requests = 1000 — в зависимост от количеството pm.max_children и броя на заявките в секунда.
На скрийншота е показан командата , филтрирана по u (user) и името на потребителя PHP-FPM. Показани са само първите 50 или нещо от порядъка на процеси (точно не съм преброил), но по същество top показва основната статистика, която се показва в терминалния прозорец. В този случай с сортиране по % ЦП (%CPU). За да видите всички 100 процеса на PHP-FPM, изпълнете командата:
top -bn1 | grep php-fpmКога да използвате pm ondemand и dynamic
Ако използвате pm dynamic, възникват подобни грешки:
WARNING: [pool xxxx] изглежда зает (може да се наложи да увеличите pm.start_servers, или pm.min/max_spare_servers), създавайки 32 деца, има 4 бездействващи и 59 общо децаОпитайте да промените параметъра, грешката няма да изчезне, както . В този случай стойността на pm.min е била твърде малка и тъй като уеб трафикът се променя значително, с високи пикове и дълбоки спадове, е трудно адекватно да се настрои pm dynamic. Обикновено в този случай се използва pm ondemand, . Но това е още по-лошо, защото ondemand завършва бездействващите процеси до нула, когато трафикът е малък или го няма изобщо, и в крайна сметка все пак ще се сблъскате с разходите при промяната на трафика. Освен ако, разбира се, не сте задали огромно време на изчакване. И тогава е по-добре да използвате pm.static + високо число pm.max_requests.
PM dynamic и особено ondemand могат да бъдат полезни, ако имате няколко пула PHP-FPM. Например, ако хоствате няколко акаунта cPanel или няколко уебсайта в различни пулове. Имам сървър, където, да кажем, 100+ акаунта cPanel и около 200 домейна, а pm.static или дори dynamic не биха ми помогнали. Тук е нужен само ondemand, защото повече от две трети от уебсайтовете получават малко трафик или изобщо никакъв, а с ondemand всички дъщерни процеси ще паднат, което ще спести много памет за нас! За щастие, разработчиците на cPanel забелязаха това и установиха стойността по подразбиране ondemand. Преди, когато стойността по подразбиране беше dynamic, PHP-FPM изобщо не беше подходящ за натоварени общи сървъри. Много хора използваха suPHP, защото pm dynamic консумираше памет, дори при бездействващи пулове и акаунти cPanel PHP-FPM. Най-вероятно, при добър трафик, няма да хоствате на сървър с много пулове PHP-FPM (общ хостинг).
Заключение
Ако използвате PHP-FPM и трафикът ви е сериозен, мениджърите на процеси ondemand и dynamic за PHP-FPM ще ограничават пропускателната способност поради присъщите разходи. Изследвайте системата си и настройте процесите PHP-FPM според максималната капацитета на сървера. Първо задайте pm.max_children в зависимост от максималното използване на pm dynamic или ondemand, след това увеличете тази стойност до ниво, при което паметта и процесорът работят без прекомерно натоварване. Ще забележите, че с pm static, тъй като всичко е съхранено в паметта, пиковете на трафика с времето ще предизвикат по-малко натоварване на процесора, а средните стойности на натоварването на сървъра и процесора ще се изравнят. Средният размер на процеса PHP-FPM зависи от уеб сървъра и изисква ръчна настройка, затова по-автоматизираните мениджъри на процеси - dynamic и ondemand - са по-популярни. Надявам се, че статията е била полезна.
UPD Добавена диаграма на бенчмарка . Когато процесите PHP-FPM са в паметта, производителността нараства за сметка на потреблението на паметта, където те седят и чакат. Намерете оптималния вариант за вас.
Източник: habr.com
