Неадрэдагаваная версія артыкула была першапачаткова апублікавана на і публікуецца тут з дазволу яе .
Я ў двух словах раскажу, як лепш за ўсё наладзіць PHP-FPM, каб павялічыць прапускную здольнасць, знізіць затрымку і больш стабільна выкарыстоўваць працэсарныя рэсурсы і памяць. Па змаўчанні радок PM (process manager, мэнэджар працэсаў) у PHP-FPM мае значэнне дынамічны, а калі ў вас не хапае памяці, то лепш усталяваць па патрабаванню. Давайце параўнаем 2 варыянты кіравання на аснове дакументацыі php.net і паглядзім, чым ад іх адрозніваецца мой каханы статычны 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, могуць павысіць прадукцыйнасць і хуткасць водгуку сістэмы, калі змяніць параметр рэгулятара працэсара з па патрабаванню на performance*. На гэты раз давайце параўнаем апісанні і паглядзім на падабенствы:
Governor = ondemand - дынамічнае маштабаванне частаты працэсара ў залежнасці ад бягучай нагрузкі. Рэзка пераходзіць на максімальную частату, а затым змяншае яе, калі павялічваюцца перыяды прастою.
Governor = conservative = дынамічнае маштабаванне частаты ў залежнасці ад бягучай нагрузкі. Павялічвае і памяншае частату плыўней, чым ondemand.
Governor = performance - Частата заўсёды максімальная.
Падрабязнасці гл. у .
Бачыце падабенства? Я хацеў паказаць гэта параўнанне, каб пераканаць вас, што лепш за ўсё выкарыстоўваць pm static для PHP-FPM.
Для рэгулятара працэсара параметр прадукцыйнасць дапамагае бяспечна павялічыць прадукцыйнасць, таму што яна амаль поўнасцю залежыць ад ліміту працэсара сервера. Акрамя гэтага, вядома, ёсць яшчэ такія фактары, як тэмпература, зарад акумулятара (у наўтбуку) і іншыя пабочныя эфекты сталай працы працэсара на 100%. Настройка performance забяспечвае самую хуткую працу працэсара. Пачытайце, напрыклад, аб , з якім панэль RPi будзе выкарыстоўваць рэгулятар прадукцыйнасць, дзе паляпшэнне прадукцыйнасці будзе больш прыкметнымі з-за нізкай тактавай частаты ЦП.
Выкарыстанне pm static для дасягнення максімальнай прадукцыйнасці сервера
Параметр PHP-FPM pm static шмат у чым залежыць ад вольнай памяці на серверы. Калі памяці мала, лепш абраць па патрабаванню або дынамічны. З іншага боку, калі ў вас ёсць памяць, можна пазбегнуць лішніх выдаткаў мэнэджара працэсу PHP, усталяваўшы pm. статычны на максімальную ёмістасць сервера. Іншымі словамі, калі ўсё добра падлічыць, трэба ўсталяваць 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 (user) і імя карыстальніка PHP-FPM. Паказана толькі першыя 50 ці каля таго працэсаў (сапраўды не лічыў), але, у сутнасці, top паказвае топ статыстыкі, якая змяшчаецца ў акно тэрмінала. У гэтым выпадку з сартаваннем па% ЦП (% 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Паспрабуйце змяніць параметр, памылка нікуды не падзенецца, як . У гэтым выпадку значэнне pm.min было занадта маленькім, а раз вэб-трафік моцна змяняецца і ў яго ёсць высокія пікі і глыбокія спады, складана адэкватна наладзіць pm дынамічны. Звычайна пры гэтым выкарыстоўваецца pm па патрабаванню, . Але гэта яшчэ горш, бо па патрабаванню завяршае бяздзейныя працэсы да нуля, калі трафіку мала ці не наогул, і ў выніку вы ўсё роўна будзеце пакутаваць з выдаткамі пры змене трафіку. Калі, вядома, вы не ўсталявалі велізарны час чакання. І тады лепш ужо выкарыстоўваць pm.static + высокая колькасць pm.max_requests.
PM дынамічны і асабліва па патрабаванню могуць спатрэбіцца, калі ў вас некалькі пулаў PHP-FPM. Напрыклад, вы размяшчае некалькі акаўнтаў cPanel або некалькі вэб-сайтаў у розных пулах. У мяне ёсць сервер, дзе, дапусцім, 100+ акаўнтаў cpanel і прыкладна 200 даменаў, і pm.static ці нават dynamic мяне б не выратаваў. Тут патрэбен толькі па патрабаванню, бо больш за дзве траціны вэб-сайтаў атрымліваюць мала трафіку або наогул ніякага, а з па патрабаванню усе даччыныя працэсы адваляцца, што зэканоміць нам плойму памяці! Да шчасця, распрацоўнікі cPanel гэта заўважылі і ўсталявалі значэнне па змаўчанні па патрабаванню. Раней, калі значэннем па змаўчанні быў дынамічны, PHP-FPM наогул не падыходзіў для нагружаных агульных сервераў. Многія выкарыстоўвалі suPHP, таму што pm дынамічны спажываў памяць нават пры бяздзейных пулах і акаўнтах cPanel PHP-FPM. Хутчэй за ўсё, пры добрым трафіку вы не будзеце размяшчацца на серверы з вялікай колькасцю пулаў PHP-FPM (агульны хостынг).
Заключэнне
Калі вы карыстаецеся PHP-FPM і трафік у вас сур'ёзны, менеджэры працэсаў па патрабаванню и дынамічны для PHP-FPM будуць абмяжоўваць прапускную здольнасць з-за ўласцівых ім выдаткаў. Вывучыце сваю сістэму і наладзьце працэсы PHP-FPM у адпаведнасці з максімальнай ёмістасцю сервера. Спачатку задайце pm.max_children у залежнасці ад максімальнага выкарыстання pm дынамічны або па патрабаванню, а затым павялічце гэта значэнне да ўзроўню, дзе памяць і працэсар будуць працаваць без празмернай перагрузкі. Вы заўважыце, што з pm static, раз у вас усё захоўваецца ў памяці, пікі трафіку з часам будуць выклікаць менш пікаў для працэсара, а сярэднія значэнні нагрузкі сервера і працэсара выраўнуюцца. Сярэдні памер працэсу PHP-FPM залежыць ад вэб-сервера і патрабуе налады ўручную, таму больш аўтаматызаваныя менеджэры працэсаў. дынамічны и па патрабаванню - больш папулярныя. Спадзяюся, артыкул быў карысным.
ДУП Дададзеная дыяграма бенчмарку . Калі працэсы PHP-FPM знаходзяцца ў памяці, прадукцыйнасць павялічваецца за рахунак спажывання памяці, дзе яны сядзяць і чакаюць. Знайдзіце для сябе аптымальны варыянт.
Крыніца: habr.com