PHP-FPM կարգավորում. առավելագույն արդյունավետության համար օգտագործեք pm ստատիկ

Այս հոդվածի չխմբագրված տարբերակը ի սկզբանե հրապարակվել է haydenjames.io և նրա թույլտվությամբ հրապարակվել է այստեղ հեղինակ.

Ես ձեզ կարճ կասեմ, թե ինչպես լավագույնս կարգավորել PHP-FPM-ը, որպեսզի մեծացնեք թողունակությունը, նվազեցնեք հետաձգումը և ավելի հետևողականորեն օգտագործեք պրոցեսորն ու հիշողությունը: Լռելյայնորեն, PHP-FPM-ում PM (գործընթացի կառավարիչ) տողն է դինամիկ, իսկ եթե բավարար հիշողություն չունեք, ապա ավելի լավ է տեղադրել ըստ պահանջի. Եկեք համեմատենք php.net փաստաթղթերի վրա հիմնված կառավարման 2 տարբերակ և տեսնենք, թե ինչպես է իմ սիրելին տարբերվում դրանցից ստատիկ 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-ը կարող են բարելավել համակարգի աշխատանքը և արձագանքողությունը՝ փոխելով պրոցեսորի շնչափողի կարգավորումը ըստ պահանջի մասին կատարում*. Այս անգամ եկեք համեմատենք նկարագրությունները և նայենք նմանություններին.

մարզպետ=պահանջ — պրոցեսորի հաճախականության դինամիկ չափում` կախված ընթացիկ բեռից: Արագորեն ցատկում է առավելագույն հաճախականության, այնուհետև նվազեցնում է այն, քանի որ անգործության ժամանակաշրջանները մեծանում են:
մարզպետ=պահպանողական= դինամիկ հաճախականության սանդղակ՝ կախված ընթացիկ բեռից: Բարձրացնում և նվազեցնում է հաճախականությունը ավելի սահուն, քան պահանջով:
Մարզպետ = կատարում — հաճախականությունը միշտ առավելագույնն է:

Մանրամասների համար տե՛ս պրոցեսորի հաճախականության կարգավորիչի պարամետրերի ամբողջական ցանկը.

Տեսնո՞ւմ եք նմանությունները: Ես ուզում էի ցույց տալ այս համեմատությունը, որպեսզի համոզեմ ձեզ, որ դա լավագույնն է օգտագործել pm ստատիկ PHP-FPM-ի համար:

Պրոցեսորի կարգավորիչի պարամետրի համար կատարումը օգնում է ապահով կերպով բարձրացնել կատարումը, քանի որ այն գրեթե ամբողջությամբ կախված է սերվերի պրոցեսորի սահմանաչափից: Բացի սրանից, իհարկե, կան նաև այնպիսի գործոններ, ինչպիսիք են ջերմաստիճանը, մարտկոցի լիցքը (նոութբուքում) և պրոցեսորը 100%-ով անընդհատ աշխատելու այլ կողմնակի ազդեցությունները: Կատարման կարգավորումն ապահովում է պրոցեսորի ամենաարագ աշխատանքը: Կարդացեք, օրինակ, մասին force_turbo պարամետր Raspberry Pi-ումորի հետ RPi վահանակը կօգտագործի կարգավորիչը կատարումը, որտեղ կատարողականի բարելավումն ավելի նկատելի կլինի պրոցեսորի ցածր ժամացույցի արագության պատճառով։

Օգտագործելով pm ստատիկ սերվերի առավելագույն արդյունավետությունը

PHP-FPM տարբերակ pm ստատիկ մեծապես կախված է սերվերի ազատ հիշողությունից: Եթե ​​հիշողությունը ցածր է, ավելի լավ է ընտրել ըստ պահանջի կամ դինամիկ. Մյուս կողմից, եթե հիշողություն ունեք, կարող եք խուսափել PHP գործընթացի կառավարիչից՝ pm-ը դնելով ստատիկ մինչև սերվերի առավելագույն հզորությունը: Այսինքն, եթե ամեն ինչ լավ հաշվարկված է, պետք է հաստատել pm.static մինչև PHP-FPM գործընթացների առավելագույն ծավալը, որը կարող է իրականացվել, առանց հիշողության կամ քեշի հետ խնդիրներ ստեղծելու: Բայց ոչ այնքան բարձր, որ այն ծանրաբեռնի պրոցեսորները և կուտակի PHP-FPM գործողություններ, որոնք սպասում են կատարմանը:.

Վերևի սքրինշոթում սերվերն ունի pm = ստատիկ և pm.max_children = 100, և սա մոտ 10 ԳԲ է վերցնում առկա 32-ից: Ուշադրություն դարձրեք ընդգծված սյունակներին, այստեղ ամեն ինչ պարզ է: Այս սքրինշոթում Google Analytics-ում կար մոտավորապես 200 ակտիվ օգտատեր (ավելի քան 60 վայրկյան): Այս մակարդակում PHP-FPM երեխայի գործընթացների մոտավորապես 70%-ը դեռ անգործուն է: Սա նշանակում է, որ 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 և վայրկյանում հարցումների քանակը:

Սքրինշոթը ցույց է տալիս հրամանը Linux-ի վերև, զտված u (օգտագործողի) և PHP-FPM օգտանունով: Ցուցադրվում են միայն առաջին մոտ 50 պրոցեսները (ես ճիշտ չեմ հաշվել), բայց ըստ էության վերևում ցուցադրվում են լավագույն վիճակագրությունը, որը տեղավորվում է տերմինալի պատուհանում: Այս դեպքում տեսակավորված ըստ % CPU (%CPU): Բոլոր 100 PHP-FPM գործընթացները տեսնելու համար գործարկեք հրամանը.

top -bn1 | grep php-fpm

Երբ օգտագործել pm ondemand և դինամիկ

Եթե ​​օգտագործում եք 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 ըստ պահանջի, ինչպես խորհուրդ է տրվում նույն գրառման մեջ. Բայց սա ավելի վատ է, քանի որ ըստ պահանջի դադարեցնում է անգործուն գործընթացները մինչև զրոյի, երբ երթևեկությունը քիչ է կամ ընդհանրապես բացակայում է, և դուք դեռևս կունենաք երթևեկի փոփոխման ծախսերը: Եթե, իհարկե, մեծ սպասման ժամանակ չեք սահմանել: Եվ հետո ավելի լավ է օգտագործել pm.static + բարձր թիվ pm.max_requests.

PM դինամիկ եւ հատկապես ըստ պահանջի կարող է օգտակար լինել, եթե ունեք բազմաթիվ PHP-FPM լողավազաններ: Օրինակ, դուք հյուրընկալում եք մի քանի cPanel հաշիվներ կամ բազմաթիվ կայքեր տարբեր լողավազաններում: Ես սերվեր ունեմ, ասենք, 100+ cpanel հաշիվներով և մոտ 200 դոմեններով, և pm.static կամ նույնիսկ դինամիկ ինձ չեն փրկի։ Ձեզ անհրաժեշտ է միայն այստեղ ըստ պահանջի, ի վերջո, կայքերի ավելի քան երկու երրորդը քիչ տրաֆիկ է ստանում կամ ընդհանրապես բացակայում է, և հետ ըստ պահանջի բոլոր մանկական գործընթացները կընկնեն, ինչը մեզ շատ հիշողություն կփրկի: Բարեբախտաբար, cPanel-ի մշակողները դա նկատեցին և արժեքը դրեցին լռելյայն ըստ պահանջի. Նախկինում, երբ լռելյայն էր դինամիկ, PHP-FPM-ն ընդհանրապես հարմար չէր զբաղված համօգտագործվող սերվերների համար։ Շատերն են օգտագործել suPHP, քանի որ pm դինամիկ սպառում է հիշողությունը նույնիսկ անգործուն լողավազանների և cPanel PHP-FPM հաշիվների դեպքում: Ամենայն հավանականությամբ, եթե տրաֆիկը լավ է, դուք չեք հոսթինգի ենթարկվի մեծ թվով PHP-FPM լողավազաններով (համօգտագործվող հոսթինգ) սերվերի վրա։

Ամփոփում

Եթե ​​դուք օգտագործում եք PHP-FPM և ձեր երթևեկությունը մեծ է, գործընթացի կառավարիչները ըստ պահանջի и դինամիկ PHP-FPM-ի համար սահմանափակ թողունակություն կլինի՝ իրենց բնորոշ վերադիր ծախսերի պատճառով: Հասկացեք ձեր համակարգը և կազմաձևեք PHP-FPM գործընթացները՝ ըստ սերվերի առավելագույն հզորության: Առաջին հավաքածու pm.max_children կախված առավելագույն pm օգտագործումից դինամիկ կամ ըստ պահանջի, և այնուհետև այս արժեքը բարձրացրեք այն մակարդակի, որտեղ հիշողությունը և պրոցեսորը կաշխատեն առանց ծանրաբեռնվածության: Դուք կնկատեք, որ հետ pm ստատիկ, քանի որ դուք ունեք ամեն ինչ հիշողության մեջ, երթևեկության աճերը ժամանակի ընթացքում կհանգեցնեն CPU-ի ավելի քիչ աճի, իսկ սերվերի և պրոցեսորի բեռնվածության միջին ցուցանիշները կհավասարվեն: PHP-FPM գործընթացի միջին չափը կախված է վեբ սերվերից և պահանջում է ձեռքով կազմաձևում, ուստի ավելի շատ ավտոմատացված գործընթացների կառավարիչներ են դինամիկ и ըստ պահանջի - ավելի հայտնի: Հուսով եմ, որ հոդվածը օգտակար էր:

DUP Ավելացվեց հենանիշային աղյուսակ ab. Եթե ​​PHP-FPM պրոցեսները հիշողության մեջ են, կատարումը մեծանում է հիշողության սպառման հաշվին, որտեղ նրանք նստած և սպասում են: Գտեք լավագույն տարբերակը ձեզ համար:

Source: www.habr.com