Настройка на PHP-FPM: използвайте pm static за максимална производителност

Нередактирана версия на тази статия първоначално е публикувана на haydenjames.io и публикувани тук с нейно разрешение автор.

Ще ви кажа накратко как най-добре да конфигурирате PHP-FPM, за да увеличите пропускателната способност, да намалите латентността и да използвате процесора и паметта по-последователно. По подразбиране редът PM (мениджър на процеси) в PHP-FPM е динамичен, и ако нямате достатъчно памет, тогава е по-добре да инсталирате OnDemand. Нека сравним 2 опции за управление въз основа на документацията на php.net и да видим как моят любим се различава от тях статичен pm за голям трафик:

pm = динамичен — броят на дъщерните процеси се конфигурира динамично въз основа на следните директиви: pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers.
pm = при поискване - процесите се създават при поискване (за разлика от динамичното създаване, когато pm.start_servers се стартират при стартиране на услугата).
pm = статичен — броят на дъщерните процеси е фиксиран и се указва от параметъра pm.max_children.

За подробности вж пълен списък на глобалните директиви php-fpm.conf.

Прилики между мениджъра на процеси PHP-FPM и контролера на честотата на процесора

Това може да изглежда извън темата, но ще го свържа с темата за конфигурацията на PHP-FPM. Кой не е имал поне веднъж забавяне на процесора - на лаптоп, виртуална машина или специален сървър. Помните ли мащабирането на честотата на процесора? Тези опции са налични за nix и Windows могат да подобрят производителността и отзивчивостта на системата, като променят настройката на дросела на процесора от OnDemand на производителност*. Този път нека сравним описанията и да разгледаме приликите:

губернатор=по заявка — динамично мащабиране на честотата на процесора в зависимост от текущото натоварване. Бързо скача до максимална честота и след това я намалява с увеличаване на периодите на неактивност.
губернатор=консерватор= динамично мащабиране на честотата в зависимост от текущото натоварване. Увеличава и намалява честотата по-плавно от при поискване.
Губернатор = изпълнение — честотата винаги е максимална.

За подробности вж пълен списък на параметрите на регулатора на честотата на процесора.

Вижте приликите? Исках да покажа това сравнение, за да ви убедя, че е най-добре да го използвате pm static за PHP-FPM.

За параметъра на регулатора на процесора пърформанс помага за безопасно увеличаване на производителността, тъй като тя е почти изцяло зависима от лимита на процесора на сървъра. В допълнение към това, разбира се, има и фактори като температура, заряд на батерията (в лаптоп) и други странични ефекти от постоянното пускане на процесора на 100%. Настройката за производителност гарантира най-бързата производителност на процесора. Прочетете например за параметър force_turbo в Raspberry Piс който панелът RPi ще използва регулатора пърформанс, където подобрението на производителността ще бъде по-забележимо поради ниската тактова честота на процесора.

Използване на pm static за постигане на максимална производителност на сървъра

PHP-FPM опция pm static до голяма степен зависи от свободната памет на сървъра. Ако паметта е малко, по-добре е да изберете OnDemand или динамичен. От друга страна, ако имате памет, можете да избегнете претоварването на мениджъра на процеси на PHP, като зададете pm статичен до максималния капацитет на сървъра. С други думи, ако всичко е изчислено добре, трябва да установите pm.статичен до максималния обем PHP-FPM процеси, които могат да бъдат изпълнени, без да създава проблеми с ниска памет или кеш. Но не толкова висока, че да претовари процесорите и да натрупа куп PHP-FPM операции, чакащи да бъдат изпълнени.

На екранната снимка по-горе сървърът има pm = статичен и pm.max_children = 100, и това заема приблизително 10 GB от наличните 32. Обърнете внимание на маркираните колони, тук всичко е ясно. На тази екранна снимка имаше приблизително 200 активни потребители (повече от 60 секунди) в Google Анализ. На това ниво приблизително 70% от дъщерните процеси на PHP-FPM все още са неактивни. Това означава, че PHP-FPM винаги е настроен на максималното количество сървърни ресурси, независимо от текущия трафик. Неактивен процес изчаква пикове на трафика и реагира незабавно. Не е нужно да чакате, докато pm ще създаде дъщерни процеси и след това ще ги прекрати, когато периодът изтече pm.process_idle_timeout. Зададох стойността на много висока pm.max_requestsзащото това е работещ сървър без изтичане на памет в PHP. Можете да инсталирате pm.max_requests = 0 със статични, ако сте напълно уверени в съществуващите и бъдещите PHP скриптове. Но е по-добре да стартирате отново скриптовете след време. Задайте голям брой заявки, защото искаме да избегнем ненужните pm разходи. Например поне pm.max_requests = 1000 - в зависимост от количеството pm.max_children и броя на заявките в секунда.

Екранната снимка показва командата Linux топ, филтриран по u (потребител) и PHP-FPM потребителско име. Показани са само първите 50 или повече процеса (не броих точно), но по същество top показва най-добрите статистики, които се побират в прозореца на терминала. В този случай сортирани по % CPU (%CPU). За да видите всички 100 PHP-FPM процеса, изпълнете командата:

top -bn1 | grep php-fpm

Кога да използвате pm ondemand и dynamic

Ако използвате pm динамичен, възникват грешки като тази:

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 children

Опитайте да промените параметъра, грешката няма да изчезне, например описан в тази публикация на Serverfault. В този случай стойността на pm.min беше твърде малка и тъй като уеб трафикът варира толкова много и има високи върхове и дълбоки падини, е трудно да се коригира адекватно pm динамичен. Обикновено се използва pm OnDemand, както се препоръчва в същата публикация. Но това е още по-лошо, защото OnDemand прекратява неактивните процеси до нула, когато има малък или никакъв трафик, и пак ще се окажете с режийни разходи за промяна на трафика. Освен ако, разбира се, не зададете огромно време за изчакване. И тогава е по-добре да се използва pm.статичен + високо число pm.max_requests.

PM динамичен и по-специално OnDemand може да бъде полезно, ако имате множество PHP-FPM пулове. Например хоствате множество акаунти в cPanel или множество уебсайтове в различни пулове. Имам сървър с, да речем, 100+ cpanel акаунта и около 200 домейна и pm.static или дори dynamic не биха ме спасили. Всичко, от което се нуждаете тук е OnDemand, в края на краищата, повече от две трети от уебсайтовете получават малък или никакъв трафик, а със OnDemand всички дъщерни процеси ще отпаднат, което ще ни спести много памет! За щастие, разработчиците на cPanel забелязаха това и зададоха стойността по подразбиране OnDemand. Преди, когато по подразбиране беше динамичен, PHP-FPM изобщо не беше подходящ за натоварени споделени сървъри. Много са използвали suPHP, защото ч динамичен консумирана памет дори при неактивни пулове и cPanel PHP-FPM акаунти. Най-вероятно, ако трафикът е добър, няма да бъдете хоствани на сървър с голям брой PHP-FPM пулове (споделен хостинг).

Заключение

Ако използвате PHP-FPM и трафикът ви е голям, мениджъри на процеси OnDemand и динамичен за PHP-FPM ще бъде ограничена пропускателна способност поради присъщите им допълнителни разходи. Разберете вашата система и конфигурирайте PHP-FPM процесите според максималния капацитет на сървъра. Първи набор pm.max_children в зависимост от максималната употреба на вечерта динамичен или OnDemandи след това увеличете тази стойност до ниво, при което паметта и процесорът ще работят без претоварване. Ще забележите, че с pm static, тъй като имате всичко в паметта, пиковете на трафика ще доведат до по-малко пикове на процесора с течение на времето и средните стойности на натоварването на сървъра и процесора ще се изравнят. Средният размер на PHP-FPM процеса зависи от уеб сървъра и изисква ръчна конфигурация, така че са по-автоматизирани мениджъри на процеси динамичен и OnDemand - по популярен. Надявам се статията да е била полезна.

DUP Добавена бенчмарк диаграма ab. Ако процесите на PHP-FPM са в паметта, производителността се увеличава за сметка на потреблението на памет, където стоят и чакат. Намерете най-добрия вариант за себе си.

Източник: www.habr.com