Нерегламентираната версия на статията първоначално е публикувана на и се публикува тук с разрешение на нея .
Ще спомена накратко как най-добре да настроите PHP-FPM, за да увеличите пропускната способност, да намалите закъснението и по-стабилно да използвате процесорните ресурси и паметта. По подразбиране редът PM (мениджър на процесите) в PHP-FPM има стойност dynamic, а ако имате недостатъчно памет, е по-добре да зададете ondemand. Нека сравним двата варианта на управление на базата на документацията 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 ГБ от наличните 32. Обърнете внимание на подчертаните колони, тук всичко е ясно. На този екран имаше около 200 активни потребители (над 60 секунди) в Google Analytics. На това ниво около 70% от децата на процесите PHP-FPM все още са неактивни. Това означава, че PHP-FPM винаги е настроен на максималния обем ресурси на сървера, независимо от текущия трафик. Процесът в неактивен режим чака пиковете на трафика и реагира незабавно. Не е нужно да чакате, докато pm създаде дъщерни процеси и след това да ги приключи, когато изтече периодът pm.process_idle_timeout. Зададох много голяма стойност за pm.max_requests, защото това е работещ сървър без паметни течове в PHP. Можете да зададете pm.max_requests = 0 с static, ако напълно сте сигурни в наличните и бъдещите PHP скриптове. Но е по-добре да рестартирате скриптовете с времето. Задайте високо число на заявките, тъй като искаме да избегнем излишните разходи на pm. Например, поне pm.max_requests = 1000 — в зависимост от броя pm.max_children и броя на заявките в секунда.
На екрана е показана команда , филтриран по u (потребител) и името на потребителя 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
