Axion raportti php pm. PHP:n ottaminen vakavasti. Käytä pm=statica palvelimesi suorituskyvyn maksimoimiseksi

Tutkittuani luonnoksiani löysin varsin mielenkiintoisen aiheen - prosessihallinnan asettamisen php-fpm:lle ja nginxille. Yritän tarjota mahdollisimman paljon tietoa tästä aiheesta. Kerron sinulle visuaalisilla esimerkeillä, mikä on parempi ja kuinka jotkut tärkeät parametrit lasketaan php-fpm:ssä.

Joten mikä on "prosessinhallinta" php-fpm: ssä? Prosessinhallinta php-fpm:ssä on PHP-FPM:n prosessinhallinta, joka luo ja käyttää PHP-prosesseja saadakseen kaiken irti palvelimestasi.

Prosessinhallinnan tyypit php-fpm:ssä:

• dynaaminen — Sillä on dynaaminen pm.max_children-määrä (lapsiprosessit). Joka muuttuu ja asetetaan seuraavien perusteella: pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers.
• staattinen - Siinä on kiinteä määrä pm.max_children (lapsiprosessit).
• ondemand - Lapsiprosesseja ei aloiteta aivan alusta. Prosessien määrä luodaan pyynnöstä (kuten pyynnöt näkyvät, toisin kuin PM dynaaminen, kun tietty määrä prosesseja, joka on yhtä suuri kuin pm.start_servers, käynnistetään palvelun käynnistyessä.

Nämä ovat php-fpm:n kolme pääprosessinhallintaa.

Prosessinhallinnan asettaminen dynaamiseksi php-fpm:lle Unix/Linuxissa

Tavallinen prosessinhallinta ja se on hyvä, koska siinä on useita PHP-FPM-mastereja.

Ja niin, muokkaamme pooliamme ja asetamme:

Pm = dynaaminen

Ja niin, nyt voit määrittää prosessien enimmäismäärän. Tähän on olemassa kaava:

Prosessien enimmäismäärä = (RAM yhteensä - (Käytetty muisti + puskuri)) / (Muisti per php-prosessi)

Oletetaan, että palvelimella on 6 Gt RAM-muistia, mutta näet sen seuraavalla apuohjelmalla:

# kissa /proc/meminfo | grep -E "MemTotal" MemTotal: 6291456 kB

Tarkistamme kuinka paljon muistia PHP-FPM käyttää seuraavalla komennolla:

# ps -aylC "php-fpm" | grep -Ev "grep" | lajitella -n | awk "(sum+=$8; ++n) END (print "Tot="sum"("n"";print "Avg="sum"/"n"="sum/n/1024"MB)" Tot= 3126148(46) Avg=3126148/46=66.3669 Mt

Listaaksesi kaikki php-fpm-prosessit käytä:

# ps --no-headers -o "rss,cmd" -C php-fpm | lajitella -n | awk "(tulosta $1/1024 "Mb)"

Rasvaisin prosessi:

# ps --no-headers -o "rss,cmd" -C php-fpm | lajitella -n | awk "(tulosta $1/1024,"Mb")" | häntä -n1

Toinen tapa:

Ensimmäisellä välilehdellä suoritamme:

#vaikka totta; tee curl https://site &> /dev/null; nukkua 1; tehty

Toisella välilehdellä suoritamme tarkistuksen:

Jälleen näytin luettelon kaikista prosesseista. Päätät itse, mitä teet ja otat keskiarvon tai korkeintaan maksimiarvon. Kaikki pitää testata! Prosessien käyttämän muistin määrä voidaan tarkistaa ps_mem-apuohjelmalla:

Sitten voidaan laskea prosessien enimmäismäärä (päätin antaa kaiken RAM-muistin PHP:lle):

(1024*6) / 66 = 93.0909

Näemme, että voit käyttää enintään 93 palvelinta php-fpm: lle:

Pm = dynaaminen pm.max_children = 93 pm.start_servers = 30 pm.min_spare_servers = 30 pm.max_spare_servers = 45 pm.process_idle_timeout = 10s;

Pääparametrit:

• pm = dynaaminen - Kuten jo mainittiin, tämä on prosessinhallinta. pm = dynaaminen
• pm.max_children — Asettaa PM:n luomien aliprosessien (jälkeläisprosessien) enimmäismäärän. pm.max_children= (Välimuistin kokonaismäärä)/(1 php-prosessille varattu muisti) = 93
• pm.start_servers - Asettaa aliprosessien määrän, jotka PM luo, kun PHP-FMP käynnistetään. pm.start_servers = ~(pm.max_children/3) = 31
• pm.min_spare_servers — Asettaa prosessien lukumäärän, joiden tulee jäädä valmiustilaan "varaksi", jotka odottavat tehtävien suorittamista, jos määrä on pienempi, luodaan uusia; pm.min_spare_servers = (asetettu 1 ytimeen) TAI ~(pm.max_children/3) = 31
• pm.max_spare_servers - päinvastoin, suurin määrä prosesseja, joiden pitäisi pysyä käyttämättömänä, jos määrä on suurempi, osa lapsista tuhoutuu: pm.max_spare_servers = (ydinten kokonaismäärä) TAI ~(pm.max_children/2) = 45
• pm.max_requests – prosessin pyyntöjen määrä, jonka jälkeen se luodaan uudelleen, mikä on hyödyllistä muistivuotojen estämisessä; pm.max_requests = 100000
• pm.process_idle_timeout — aika sekunteina, jonka jälkeen käyttämätön prosessi poistetaan. pm.process_idle_timeout = 10 s

Huomaa, että en ottanut (Käytetty ram + puskuri) huomioon. Tämä olisi tarpeen, jos palvelimella olisi tietokantoja:

# kissa /proc/meminfo | grep -E "(MemTotal|MemFree|Cached)" MemTotal: 6291456 kB MemFree: 1678704 kB Välimuisti: 2205940 kB

Voit tarkistaa puskurin ja muistin käytön seuraavalla komennolla:

# vapaa -m yhteensä käytetty ilmainen jaettu buff/välimuisti Muisti: 6144 1521 1622 641 3000 3716 Vaihto: 0 0 0

Prosessien enimmäismäärä = (6144 - (1521 + 3000)) / 66 = 24

Käynnistä php-fpm-palvelu uudelleen:

# palvelu php-fpm käynnistyy uudelleen

Nyt käytämme htop/topia ja ab:ta tarkistaaksemme, mikä ja miten se toimii.

Suoritamme testin:

Ab -n 10000 -c 500 http://localhost/index.php

# cd /usr/local/src && wget https://site/wp-content/uploads/scripts/php-fpm/php-fpmpal.sh -q -O - | lyödä

Antaa aika hyvät ohjeet:

() (((*)\) (/()\))\))\) (` ((()/()\())(()/(()/(()/()) \))())\ /(_))((_)\ /(_)) /(_)) /(_))((_)()\ `) (/((_) (_ )) _((_)(_)) (_))_|(_)) (_()((_) /(/()(_)) _ | _ \ | || || _ \ ___ |_ |. _ \ | \)/ _| |_|_| ============================== |_| ======================= = AH00558: httpd: Palvelimen täydellistä verkkotunnusta ei voitu määrittää luotettavasti käyttämällä 31.187.70.238 Aseta komento "ServerName" maailmanlaajuisesti estämään tämä viesti AH00558: httpd: Palvelimen täydellistä verkkotunnuksen nimeä ei voitu määrittää luotettavasti käyttämällä koodia 31.187.70.238. Aseta "ServerName" -käsky globaalisti estääksesi tämän viestin ===== PHP-FPM-poolien luettelo ===== --- nagios --- Asetustiedosto: /etc/php-fpm d/nagios.conf Prosessien luettelo: 53028 53029 53030 53031 53032 Prosessien määrä: 5 Nykyinen max_children-arvo. : 50 Varaston muistin kokonaiskäyttö kilotavuina: 54440 Keskimääräinen muistin käyttö prosessia kohden kilotavuina: 10888 potentiaalinen muistin kokonaiskäyttö poolissa (keskimääräisen prosessin perusteella) (KB): 544400 Tämän poolin suurin prosessi on (KB): 10888 potentiaalinen kokonaismäärä poolin muistin käyttö (perustuu suurimpaan prosessiin) (KB): 544400 --- www --- Asetustiedosto: /etc/ php-fpm.d/www.conf Prosessien luettelo: 53033 53034 53035 53036 53037 53038 530439 530401 53042 53043 53044 53045 53046 53047 53048 53049 53050 53051 53052 53053 53054 53055 53056 53058 30 30 50 062 53083 53119 53434 53491 61608 73379 Prosessien lukumäärä: 36 Nykyinen max_children-arvo: 50 Varaston kokonaismuistin käyttö kilotavuina: 2295440 Keskimääräinen muistin käyttö per prosessi KB:ssa: 63762 Poolin potentiaalinen muistin kokonaiskäyttö (keskimääräisen prosessin perusteella) (KB): 3188100 Tämän poolin suurin prosessi on (KB): 67792 Poolin mahdollinen muistin kokonaiskäyttö (perustuen suurimpaan prosessiin) (KB): 3389600 ===== Palvelimen muistin käyttötilastot ===== Palvelimen kokonaismuistin käyttö kilotavuina: 6291456 =Apache-muistin kokonaiskäyttö kilotavuina : 0 =Nginx-muistin kokonaiskäyttö kilotavuina: 55868 =Varnish-muistin kokonaiskäyttö kilotavuina: 0 0 = MySQL-muistin kokonaiskäyttö kilotavuina: 201324.8 =PHP-FPM-muistin kokonaiskäyttö kilotavuina: 2349880 PHP-FPM-varastoille osoitettavaa muistia kilotavuina: 6099670 (vapaa muisti yhteensä + PHP-FPM:n nykyinen muistin käyttö) Potentiaalinen PHP- FPM-muistin käyttö perustuu suurimpiin prosesseihin (KB): 3934000 (64,49%) ...HYVÄ 🙂 Mahdollinen PHP-FPM-muistin kokonaiskäyttö keskimääräisen prosessikoon perusteella (KB): 3732500 (61,19%) ...HYVÄ 🙂 === == Suositukset poolia kohti ===== -- nagios -- käyttää tällä hetkellä 54440 kt muistia (2. 31 % kaikesta PHP-FPM-muistin käytöstä). Sen pitäisi voida käyttää noin 140902 kt kaikesta käytettävissä olevasta muistista. Sen keskimääräinen prosessikoko on 10 888 kt, joten tämä tarkoittaa, että max_children tulisi olla ~12. Tällä hetkellä se on asetettu arvoon 50 (tämän voi muuttaa tiedostossa /etc/php-fpm.d/nagios.conf). -- www -- käyttää tällä hetkellä 2295440 kt muistia (97,68 % kaikesta PHP-FPM-muistin käytöstä). Sen pitäisi voida käyttää noin 5958157 kt kaikesta käytettävissä olevasta muistista. Sen keskimääräinen prosessikoko on 63762 kt, joten tämä tarkoittaa, että max_children arvoksi tulisi asettaa ~93. Tällä hetkellä se on asetettu arvoon 50 (tämän voi muuttaa tiedostossa /etc/php-fpm.d/www.conf). ===== Muita huomioitavia seikkoja ===== PHP-FPM-virhelokitiedostoista (/var/log/php-fpm/error.log): - pool www oli saavuttanut max_children-arvon 50 2. tilaisuudet Näiden ryhmien kohdalla kannattaa verrata suositeltua max_children-arvoa näihin tietoihin ja päättää, olisiko suositeltu arvo tarpeeksi korkea estämään max_children-arvoon osumisen tulevaisuudessa. Huomautus: PHP-FPMpalin suorittaminen pian PHP-FPM:n tai verkkopalveluiden uudelleenkäynnistyksen jälkeen ei ole ihanteellinen. Tämä johtuu siitä, että PHP-FPMpal antaa suosituksia keskimääräisen poolin prosessikoon perusteella, ja jos PHP-FPM käynnistettiin uudelleen vähän aikaa sitten, on suuri todennäköisyys, että sivustoille ei ole tehty paljon pyyntöjä uudelleenkäynnistyksen jälkeen, ja Mittarit ovat vinossa eivätkä näytä normalisoitua keskiarvoa. On myös syytä huomata, että jos olet äskettäin käynnistänyt uudelleen palveluita, jotka yleensä kuluttavat paljon muistia, haluat todennäköisesti odottaa jonkin aikaa ennen kuin suoritat PHP-FPMpalin (esim. MySQL käyttää normaalisti 50 % muistista, mutta olet juuri käynnistänyt sen uudelleen, jolloin se saattaa käyttää vain 10 % muistista juuri nyt, joten suositukset ovat hyvin vino. =============== ==================================================== ============

Prosessinhallinnan asettaminen staattiseksi php-fpm:lle Unix/Linuxissa

Staattista prosessinhallintaa ei käytetä melkein koskaan, koska siinä on 1 PHP-FPM-masteri.

Avaa allas php-fpm:stä ja muuta parametreja:

Pm = staattinen pm.max_children = 5

Käynnistä php-fpm-palvelu uudelleen:

$ sudo-palvelu php5-fpm käynnistyy uudelleen

# palvelu php-fpm käynnistyy uudelleen

PS: Käytä komentoa käyttöjärjestelmän tyypistä riippuen.

Suoritamme testin:

# ab -n 1000 -c 10 http://localhost/index.php # ab -n 5000 -c 20 http://localhost/index.php

Lisätietoja "ab"-apuohjelmasta löytyy artikkelista:

Avaa php-fpm-poolin määritystiedosto. Löydät sen etsimällä (jos joku ei tiedä missä se on).

Poistetaan rivin kommentit "pm.max_requests"-vaihtoehdolla:

Pm.max_requests = 500

Käynnistä php-fpm uudelleen ja tarkista lataus:

# ab -n 5000 -c 20 http://localhost/index.php

Voit nähdä, että jotkut prosessit kuolivat, ja sitten jotkut prosessit tapettiin, ja sitten ne syntyivät uudelleen!

Prosessinhallinnan määrittäminen ondemand php-fpm:lle Unix/Linuxissa

Edistyksellisin (mielestäni) prosessipäällikkö. Nimestä käy ilmi, että se ei jätä prosesseja, vaan luo niitä tarpeen mukaan.

Esimerkki allas näyttää tältä:

Käyttäjä = www-data group = www-data listen = /var/run/php5-fpm/linux-notes.og/sock listen.owner = www-data listen.group = www-data listen.mode = 770 chdir = / srv/www/wp-content/linux-notes.og/ pm = ondemand pm.max_children = 17 pm.max_requests = 500

Pääparametrit:

• pm = ondemand - Kuten jo mainittiin, tämä on prosessinhallinta. pm = ondemand
• pm.max_children — Aseta lapsiprosessien enimmäismäärä. pm.max_children= (Virtuaalimuistin kokonaismäärä)/(1 php-prosessille varattu muisti) = 93
• pm.process_idle_timeout — Aseta aika sekunteina, jonka jälkeen tyhjäkäyntiprosessi poistetaan. pm.process_idle_timeout = 10 s
• pm.max_requests — Aseta käsiteltyjen pyyntöjen määrä, jonka jälkeen php-fpm-prosessit käynnistetään uudelleen. pm.max_requests = 100000

Jos tarvitset lisää suorituskykyä, OnDemand-prosessinhallinta ei ole sinua varten. Kuitenkin 90 % ajasta PHP-FPM-määritys OnDemand-tilassa on parempi kuin staattinen tai dynaaminen.

Aiemmissa artikkeleissa olemme arvioineet PHP:n suorituskykyä eri käyttöajoissa, lisänneet palvelinresursseja (CPU & RAM) ja vertailleet Symfony Proxya ja Varnishia - käyttäen eZ Platformia - Symfony Frameworkiin rakennettua sisällönhallintajärjestelmää.

Kokeillaan nyt epätavallista PHP-sovellusten suoritustapaa, PHP-PM.

PHP:stä tuli suosittu osittain siitä syystä, että se on erittäin helppo ja turvallinen käyttää. Jokaisen pyynnön jälkeen PHP käynnistyy tyhjästä, käynnistää sovelluksen, lähettää vastauksen ja kuolee.

PHP-kehittäjien ei tarvitse huolehtia pitkään elävän sovelluksen muistivuotojen monimutkaisuudesta, mutta samojen perustehtävien jatkuva toistaminen vaikuttaa suorituskykyyn. Opcaching auttaa parantamaan suorituskykyä, mutta työtä on vielä paljon turhaan".

Melkein kaksi vuotta sitten, helmikuussa 2014, otettiin käyttöön vaihtoehtoinen tapa käyttää PHP:tä: Tuo korkea suorituskyky PHP-sovellukseesi (ReactPHP:n avulla). Saatuaan ensin joitakin aaltoja PHP-yhteisössä, se haihtui taustalle.

Mutta se johti suoraan PHP-PM:ään ja luultavasti vaikutti PHPFastCGI:n luomiseen. Molemmat käyttävät PHP:tä jatkuvana prosessina, joka vastaa pyyntöihin, mikä mahdollistaa rutiininomaisen käynnistyksen poistamisen yhtälöstä.

Tämä lisää suorituskykyä, mutta tekee sovelluksesta alttiimman kehittäjien virheille ja muistivuotojlle pidemmän elinkaaren vuoksi. Tästä syystä menetelmää pidetään edelleen kokeellisena, mutta joidenkin mielestä se on PHP:n suorittamisen tulevaisuus.

PHP-PM tukee oletusarvoisesti Symfony Framework -sovelluksia ja eZ Platform toimii odotetusti heti laatikosta otettuna. Joten kannattaa testata, kuinka se kestää tosielämän sovelluksessa.

PHP-PM vs. PHP-FPM suorituskyky

Aiempien testien mukaisesti suoritin pyyntöjä eZ Platform Demo -asennusta vastaan. Perinteinen PHP-FPM-asennus oli käynnissä PHP 7.0.1:ssä. PHP-PM oli Nginxin takana kuormituksen tasapainottajana ja sekä HHVM 3.11 että PHP 7.0.1 testattiin.

PHP-PM:n prosessien määrä asetettiin kaksinkertaiseksi suorittimen ydinmäärään verrattuna, PHP-FPM:n max_child-raja oli 10 - Kokeile ilmaista kokeilujaksoa korkean suorituskyvyn VPS:lle UpCloudissa. Pyynnön samanaikaisuudeksi asetettiin 10. Testit suoritettiin etusivulla ja REST API -kutsuilla ilman Symfony Proxya tai muuta korkean tason välimuistia. Testit toistettiin kolme kertaa ja keskimääräiset tulokset raportoidaan.

Etusivu ilman Symfony-välityspalvelinta

Täydellisen sivun renderöinnissä PHP-PM on merkittävä etu perinteiseen PHP-FPM-asetuksiin verrattuna. PHP-FPM pysyy samassa pallokentässä PHP-PM:n kanssa. HHVM on jatkuvasti tehokkaampi kuin PHP 7 -vastine.

API-kutsuille PHP-PM-ajot tuottavat huomattavasti parempia tuloksia kuin PHP-FPM-asetukset, mikä osoittaa, että suurempi prosenttiosuus ajasta kuluu käynnistykseen, kun käsittely on minimaalista. HHVM alkaa ylhäältä, ja tasapelin jälkeen 2 prosessorilla PHP 7 tarjoaa korkeamman tuoton 4 ja 8 CPU:n asetuksilla.

PHP-FPM:n, PHP-PM:n, Symfony Proxyn ja Varnishin vertailu

Jotta numerot saadaan laajempaan perspektiiviin välimuistissa olevien tulosten kanssa, niitä verrataan Symfony Proxyed -tulosten (ajettiin PHP-FPM:llä) ja Varnishin tuloksiin.

Täyden sivun latauksissa sekä Symfony PHP Reverse Proxy että Varnish kumoavat kaikki dynaamisesti luodut sivulataukset. Hyvällä välimuististrategialla ja fragmenttien yhdistämisellä ESI:n kanssa välityspalvelintasolla ja PHP-FPM-taustajärjestelmällä saadaan todennäköisesti parhaat todelliset tulokset.

REST API -puheluille rajoitetulla käsittelyllä PHP-PM ja PHP 7 tuumaa lähempänä Symfony Proxy -suorituskykyä. Vaikka PHP-välityspalvelin on edelleen kaksi kertaa nopeampi, on syytä harkita, että vaikeasti tallennettaviin välimuistiin ja tyhjennettäviin pyyntöihin riittävän nopea dynaaminen taustaohjelma saattaa olla käytännöllinen vaihtoehto.

Johtopäätökset

Pitkäikäisten PHP-prosessien suorittaminen on edelleen uteliaisuus, mutta tulokset tarjoavat lupauksen merkittävästi parantuneesta suorituskyvystä, kun sovelluksen käynnistykseen käytetty aika on suhteellisen pitkä verrattuna käsittelyn kokonaispituuteen.

Esimerkki on jatkuvasti käynnissä oleva demoni tällä hetkellä muodikkaassa pienten API-kutsujen maailmassa. Kulissien takana niistä saattaa muodostua kaskadi pitkän ketjun yli, esim. palvelu kutsuu REST API:ta, joka kutsuu REST API:ta, joka kutsuu REST API:ta, joka kutsuu REST API:ta, joka kutsuu REST API:ta...

Valitettavasti PHP-PM ei ole vielä käytännöllinen ratkaisu tuotantopalvelujen suorittamiseen, koska sekä PHP 7 että HHVM kaatuvat ajoittain. HHVM näyttää olevan puhtaasta vatsasta johtuen hieman vakaampi PHP-PM:n parista.

FPM käyttää php.ini-syntaksia määritystiedostossaan - php-fpm.conf ja poolin määritystiedostoissa.

Luettelo globaaleista php-fpm.conf-direktiiveistä

Polku PID-tiedostoon. Oletusarvo: ei mitään.

Error_log merkkijono

Polku virhelokitiedostoon. Oletusarvo: #INSTALL_PREFIX#/log/php-fpm.log. Jos sen arvoksi on asetettu "syslog", loki lähetetään syslogd-tiedostoon sen sijaan, että se kirjoitettaisiin paikalliseen tiedostoon.

Lokitaso merkkijono

Virhelokin taso. Mahdolliset arvot: hälytys, virhe, varoitus, huomautus, debug. Oletusarvo: huomautus.

Lokiraja kokonaisluku

Lokiraja kirjatuille riveille, joka sallii yli 1024 merkin pituisten viestien kirjaamisen ilman rivitystä. Oletusarvo: 1024. Saatavilla PHP 7.3.0:sta alkaen.

Lokipuskurointi boolean

Kokeellinen kirjaus ilman ylimääräistä puskurointia. Oletusarvo: kyllä. Saatavilla PHP 7.3.0:sta alkaen.

Syslog.facility merkkijono

käytetään määrittämään, minkä tyyppinen ohjelma kirjaa viestin. Oletusarvo: daemon.

Syslog.ident merkkijono

Valmiina jokaiseen viestiin. Jos samassa palvelimessa on käynnissä useita FPM-esiintymiä, voit muuttaa oletusarvoa, jonka on vastattava yleisiä tarpeita. Oletusarvo: php-fpm.

Emergency_restart_threshold int

Jos tämä määrä lapsiprosesseja poistuu SIGSEGV:llä tai SIGBUS:lla asettaman aikavälin sisällä hätä_uudelleenkäynnistysväli, FPM käynnistyy uudelleen. Arvo 0 tarkoittaa "Pois päältä". Oletusarvo: 0 (Pois).

Emergency_restart_interval sekoitettu

Käyttämä aikaväli hätä_uudelleenkäynnistysväli määrittääksesi, milloin sulava uudelleenkäynnistys aloitetaan. Tästä voi olla hyötyä kiihdyttimen jaetun muistin tahattomien vioittumisten välttämiseksi. Käytettävissä olevat yksiköt: s(sekuntia), m(uuttia), h(ours) tai d(ays). Oletusyksikkö: sekuntia. Oletusarvo: 0 (Vinossa).

Process_control_timeout sekoitettu

Aikaraja, jossa lapsiprosessit odottavat reaktiota isännältä tuleviin signaaleihin. Käytettävissä olevat yksiköt: s(sekuntia), m(uuttia), h(ours) tai d(ays) Oletusyksikkö: sekuntia. Oletusarvo: 0.

Process.max int

FPM:n prosessien enimmäismäärä. Tämä on suunniteltu hallitsemaan maailmanlaajuista prosessien määrää käytettäessä dynaamista PM:ää useissa pooleissa. Käytä sitä varoen. Oletusarvo: 0.

Process.priority int

Määritä nice(2)-prioriteetti, jota sovelletaan pääprosessiin (vain jos asetettu). Arvo voi vaihdella -19:stä (korkein prioriteetti) 20:een (alempi prioriteetti). Oletusarvo: ei asetettu.

Daemonisoi boolean

Lähetä FPM taustalle. Aseta arvoksi "ei", jotta FPM pysyy etualalla virheenkorjausta varten. Oletusarvo: kyllä.

Rlimit_files int

Aseta avoimen tiedoston kuvaajan rlimit pääprosessille. Oletusarvo: Aseta avoimen tiedoston kuvaajan rlimit pääprosessille.

Rlimit_core int

Aseta ytimen enimmäiskoon rraja pääprosessille. Oletusarvo: 0.

Tapahtumat.mekanismi merkkijono

Määritä tapahtumamekanismi, jota FPM käyttää. Seuraavat ovat käytettävissä: select, pool, epoll, kqueue (*BSD), portti (Solaris). Oletusarvo: ei asetettu (automaattinen tunnistus).

Systemd_interval int

Kun FPM on koottu systemd-integraatiolla, määritä sekunteina aikaväli, joka kuluu tilaraportista systemd:lle. Aseta arvoksi 0 poistaaksesi käytöstä. Oletusarvo: 10.

Luettelo poolin direktiiveistä

FPM:llä voit ajaa useita prosesseja eri asetuksilla. Nämä ovat asetuksia, joita voidaan säätää allaskohtaisesti.

Kuunnella merkkijono

Osoite, johon FastCGI-pyynnöt hyväksytään. Kelvolliset syntaksit ovat: "ip.add.re.ss:port", "port", "/polku/unix/socket". Tämä vaihtoehto on pakollinen jokaiselle uima-altaalle.

Kuuntele.backlog int

Aseta kuuntelu(2) ruuhka. Arvo "-1" tarkoittaa rajoittamatonta. Oletusarvo: -1.

Listen.allowed_clients merkkijono

Luettelo niiden FastCGI-asiakkaiden IPv4-osoitteista, jotka voivat muodostaa yhteyden. Vastaa alkuperäisen PHP FastCGI:n (5.2.2+) ympäristömuuttujaa FCGI_WEB_SERVER_ADDRS. On järkevää vain tcp-kuunteluliittimellä. Jokainen osoite on erotettava pilkulla. Jos tämä arvo jätetään tyhjäksi, yhteydet hyväksytään mistä tahansa IP-osoitteesta. Oletusarvo: mikä tahansa. IPv6-osoitteet ovat sallittuja PHP 5.5.20:sta ja 5.6.4:stä lähtien.

Kuuntele omistaja merkkijono

Aseta käyttöoikeudet unix-socketille, jos sellainen on käytössä. Linuxissa luku-/kirjoitusoikeudet on asetettava, jotta yhteydet verkkopalvelimelta voidaan sallia. Monet BSD-pohjaiset järjestelmät sallivat yhteydet käyttöoikeuksista riippumatta. Oletusarvot: käyttäjä ja ryhmä on asetettu käynnissä oleviksi käyttäjiksi, tilaksi on asetettu 0660.

Kuuntele.ryhmä merkkijono

Katso kuuntele.omistaja.

Kuuntele.tila merkkijono

Katso kuuntele.omistaja.

Listen.acl_users merkkijono

Kun POSIX Access Control -luetteloita tuetaan, voit asettaa ne tällä vaihtoehdolla. Kun asetettu kuuntele.omistaja ja kuuntele.ryhmä jätetään huomiotta. Arvo on pilkuilla erotettu luettelo käyttäjänimistä. PHP 5.6.5:stä lähtien.

Listen.acl_groups merkkijono

Katso listen.acl_users. Arvo on pilkuilla erotettu luettelo ryhmien nimistä. PHP 5.6.5:stä lähtien.

Käyttäjä merkkijono

FPM-prosessien Unix-käyttäjä. Tämä vaihtoehto on pakollinen.

Ryhmä merkkijono

Unix-ryhmä FPM-prosesseja. Jos sitä ei ole asetettu, käytetään oletuskäyttäjäryhmää.

pm merkkijono

Valitse, kuinka prosessinhallinta hallitsee aliprosessien määrää. Mahdolliset arvot: staattinen, tarpeen vaatiessa, dynaaminen. Tämä vaihtoehto on pakollinen.

staattinen- lapsiprosessien määrä on kiinteä ( pm.max_children).

tarpeen vaatiessa- prosessit syntyvät kysynnän mukaan (kun niitä pyydetään, toisin kuin dynaamisesti, missä pm.start_servers käynnistyvät, kun palvelu käynnistetään.

dynaaminen- lapsiprosessien määrä asetetaan dynaamisesti seuraavien ohjeiden perusteella: pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers.

pm.max_lapset int

Kun aliprosessit luodaan pm on asetettu staattinen ja luotavien aliprosessien enimmäismäärä milloin pm on asetettu dynaaminen. Tämä vaihtoehto on pakollinen.

Tämä vaihtoehto asettaa rajan toimitettavien samanaikaisten pyyntöjen lukumäärälle. Vastaa ApacheMaxClients-direktiiviä, jossa on mpm_prefork, ja PHP_FCGI_CHILDREN-ympäristömuuttujaa alkuperäisessä PHP FastCGI:ssä.

Pm.start_servers int

Käynnistyksen yhteydessä luotujen aliprosessien määrä. Käytetty vain kun pm on asetettu dynaaminen. Oletusarvo: min_varapalvelimet + (max_spare_servers - min_spare_servers) / 2.

Pm.min_spare_servers int

Haluttu käyttämättömien palvelinprosessien vähimmäismäärä. Käytetty vain kun pm on asetettu dynaaminen

Pm.max_spare_servers int

Haluttu käyttämättömien palvelinprosessien enimmäismäärä. Käytetty vain kun pm on asetettu dynaaminen. Pakollinen myös tässä tapauksessa.

Pm.process_idle_timeout sekoitettu

Sekuntien määrä, jonka jälkeen tyhjäkäynti lopetetaan. Käytetty vain kun pm on asetettu tarpeen vaatiessa. Käytettävissä olevat yksiköt: s(sekuntia)(oletus), m(uutit), h(ours) tai d(ays). Oletusarvo: 10 s.

Pm.max_requests int

Niiden pyyntöjen määrä, jotka kunkin aliprosessin tulee suorittaa ennen uudelleensyntymistä. Tämä voi olla hyödyllistä kiertää muistivuotoja kolmannen osapuolen kirjastoissa. Pyynnön jatkuvaa käsittelyä varten määritä "0". Vastaa PHP_FCGI_MAX_REQUESTS . Oletusarvo: 0.

Pm.status_path merkkijono

URI FPM-tilasivun katseluun. Jos tätä arvoa ei ole asetettu, URI:ta ei tunnisteta tilasivuksi. Oletusarvo: ei mitään.

Ping.path merkkijono

Ping-URI FPM:n valvontasivun kutsumiseksi. Jos tätä arvoa ei ole asetettu, URI-osoitetta ei tunnisteta ping-sivuksi. Tätä voitaisiin käyttää testaamaan ulkopuolelta, että FPM on elossa ja vastaa. Huomaa, että arvon on aloitettava kauttaviivalla (/).

Ping.response merkkijono

Tätä ohjetta voidaan käyttää mukauttamaan vastausta ping-pyyntöön. Vastaus on muotoiltu tekstiksi/yksinkertaiseksi 200 vastauskoodilla. Oletusarvo: pong.

Process.priority int

Määritä mukava(2)-prioriteetti, jota sovelletaan työntekijäprosessiin (vain jos asetettu). Arvo voi vaihdella välillä -19 (korkein prioriteetti) - 20 (alempi prioriteetti). Oletusarvo: ei asetettu.

Process.dumpable boolean

Aseta prosessin dumpattava lippu (PR_SET_DUMPABLE prctl), vaikka prosessin käyttäjä tai ryhmä olisi eri kuin pääprosessin käyttäjä. Sen avulla voidaan luoda prosessin ydinvedos ja jäljittää prosessi poolin käyttäjälle. Oletusarvo: ei. PHP 7.0.29, 7.1.17 ja 7.2.5 jälkeen.

Etuliite merkkijono

Määritä polun arvioinnin etuliite

Request_terminate_timeout sekoitettu

Yksittäisen pyynnön käsittelyn aikakatkaisu, jonka jälkeen työntekijäprosessi lopetetaan. Tätä vaihtoehtoa tulee käyttää, kun "max_execution_time" ini -vaihtoehto ei jostain syystä pysäytä komentosarjan suorittamista. Arvo "0" tarkoittaa "Pois päältä". Käytettävissä olevat yksiköt: s(sekuntia)(oletus), m(uutit), h(ours) tai d(ays). Oletusarvo: 0.

request_slowlog_timeout sekoitettu

Aikakatkaisu yksittäisen pyynnön palvelemiselle, jonka jälkeen PHP-palautusjäljitetään "slowlog"-tiedostoon. Arvo "0" tarkoittaa "Pois päältä". Käytettävissä olevat yksiköt: s(sekuntia)(oletus), m(uutit), h(ours) tai d(ays). Oletusarvo: 0.

Slowlog merkkijono

Lokitiedosto hitaille pyynnöille. Oletusarvo: #INSTALL_PREFIX#/log/php-fpm.log.slow.

Rlimit_files int

Aseta avoimen tiedoston kuvaajan rlimit tämän poolin lapsiprosesseille. Oletusarvo: järjestelmän määrittämä arvo.

Rlimit_core int

Aseta suurin ydinkoon rraja aliprosesseille tässä poolissa. Mahdolliset arvot: "unlimited" tai kokonaisluku, joka on suurempi tai yhtä suuri kuin 0. Oletusarvo: järjestelmän määrittämä arvo.

Chroot merkkijono

Chroot tähän hakemistoon alussa. Tämä arvo on määritettävä absoluuttiseksi poluksi. Kun tätä arvoa ei ole asetettu, chrootia ei käytetä.

Chdir merkkijono

Chdir tähän hakemistoon alussa. Tämän arvon on oltava absoluuttinen polku. Oletusarvo: nykyinen hakemisto tai / kun chroot.

Catch_workers_output boolean

Ohjaa työntekijän stdout ja stderr päävirhelokiin. Jos sitä ei ole asetettu, stdout ja stderr uudelleenohjataan hakemistoon /dev/null FastCGI-määritysten mukaisesti. Oletusarvo: ei.

Decorate_workers_output boolean

Ota työntekijöiden tulosteen tulosteen koristelu käyttöön, kun catch_workers_output on käytössä. Oletusarvo: kyllä. Saatavilla PHP 7.3.0:sta alkaen.

Clear_env boolean

Selkeä ympäristö FPM-työntekijöissä. Estää mielivaltaisia ​​ympäristömuuttujia saavuttamasta FPM-työntekijöiden prosesseja tyhjentämällä työntekijöiden ympäristön ennen kuin tässä poolikokoonpanossa määritetyt env-muuttujat lisätään. PHP versioista 5.4.27, 5.5.11 ja 5.6.0 lähtien. Oletusarvo: Kyllä.

Security.limit_extensions merkkijono

Rajoittaa pääskriptin laajennuksia. FPM sallii jäsennyksen. Tämä voi estää määritysvirheet verkkopalvelimen puolella. Sinun tulisi rajoittaa FPM vain .php-laajennuksiin, jotta haitalliset käyttäjät eivät käyttäisi muita laajennuksia php-koodin suorittamiseen. Oletusarvo: .php .phar

Access.log merkkijono

Käyttöoikeuslokitiedosto. Oletusarvo: ei asetettu

Access.format merkkijono

Käyttölokin muoto. Oletusarvo: "%R - %u %t \"%m %r\" %s"

On mahdollista välittää lisää ympäristömuuttujia ja päivittää tietyn poolin PHP-asetuksia. Tätä varten sinun on lisättävä seuraavat asetukset poolin asetustiedostoon.

Esimerkki #1 Ympäristömuuttujien ja PHP-asetusten välittäminen pooliin

env = $HOSTNAME env = /usr/local/bin:/usr/bin:/bin env = /tmp env = /tmp env = /tmp php_admin_value = /usr/sbin/sendmail -t -i -f [sähköposti suojattu] php_flag = pois päältä php_admin_value = /var/log/fpm-php.www.log php_admin_flag = päällä php_admin_value = 32M

PHP-asetukset hyväksyttiin php_value tai php_lippu korvaa niiden aiemman arvon. Huomaa, että disable_functions tai disable_classes määrittäminen ei korvaa aiemmin määritettyjä php.ini-arvoja, vaan lisää sen sijaan uuden arvon.

Asetukset on määritetty php_admin_value ja php_admin_flag ei voi ohittaa ini_set().

5.3.3:sta alkaen PHP-asetukset on mahdollista asettaa myös web-palvelimella.

Esimerkki #2 aseta PHP-asetukset tiedostossa nginx.conf

aseta $php_value "pcre.backtrack_limit=424242"; set $php_value "$php_value \n pcre.recursion_limit=99999"; fastcgi_param PHP_VALUE $php_value; fastcgi_param PHP_ADMIN_VALUE "open_basedir=/var/www/htdocs";!}

Varoitus

Koska nämä asetukset välitetään php-fpm:lle fastcgi-otsikoina, php-fpm:n ei pitäisi olla sidottu maailmanlaajuisesti saatavilla olevaan osoitteeseen. Muuten kuka tahansa voi muuttaa PHP:n asetuksia. Katso myös

Katsotaanpa nopeasti, kuinka PHP-FPM konfiguroidaan paremmin korkeaa suorituskykyä, pientä latenssia ja vakaampaa suorittimen ja muistin käyttöä varten. Useimmissa PHP-FPM-oletusasetuksissa on rivi, jossa PM (prosessinhallinta) on asetettu dynaamiseksi, sekä suosituksia ondemandin käyttöön, jos kohtaat muistin saatavuusongelmia. Katsotaanpa kuitenkin php.net:n dokumentaatiota ja vertaillaan molempia ohjausvaihtoehtoja ja verrataan myös suosikkiasetukseeni suurelle liikenteelle... pm = static:

pm = dynaaminen- aliprosessien lukumäärä asetetaan dynaamisesti seuraavien ohjeiden perusteella: pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers.

pm = ondemand- käsittelee spawn on demand (tarvittaessa, toisin kuin dynaaminen vaihtoehto, jossa pm.start_servers käynnistetään palvelun käynnistyessä).

pm = staattinen- aliprosessien lukumäärä on määritetty pm.max_children-direktiivillä.

...voit nähdä täydellisen luettelon php-fpm.conf-ohjeista saadaksesi lisätietoja.

PHP-FPM:n prosessinhallinta on samanlainen kuin CPUFreq Governor

Tämä saattaa tuntua hieman sivulta aiheesta, mutta toivon, että se liittyy PHP-FPM-optimointiimme. Kyllä, olemme kaikki kohdanneet ongelmia prosessorin suorituskyvyn kanssa jossain vaiheessa, olipa kyseessä sitten kannettava tietokone, virtuaalikone tai oma palvelin. Muistatko suorittimen taajuuden skaalauksen? (CPUFreq-ohjain) Nämä *nix- ja Windows-käyttöjärjestelmän asetukset voivat parantaa järjestelmän suorituskykyä ja reagointikykyä muuttamalla suorittimen ohjaimen asetuksen ondemand-asetuksesta suorituskykyyn. Verrataan nyt kuvauksia ja etsitään yhtäläisyyksiä:

kuvernööri=ondemand- Lisää/vähentää prosessorin kellotaajuutta dynaamisesti järjestelmän kuormituksesta riippuen. Lähettää maksimitaajuuteen asti ja laskee sitten, kun tyhjäkäyntiaika pitenee.

Kuvernööri = konservatiivi- Samanlainen kuin ondemand, mutta taloudellisempi (edustetaan pienemmät kellotaajuudet). Taajuus kasvaa tasaisemmin.

Kuvernööri = suorituskyky- Ylläpitää prosessorin (prosessorit) suurimmalla kellotaajuudella.

...lisätietoja saat täydellisestä luettelosta CPUFreq-ohjaimen asetuksista.

Huomaatko yhtäläisyydet? Halusin ensin käyttää tätä vertailua kuvatakseni selkeämmin ja paremmin käyttösuositusta pm staattinen PHP-FPM on ensimmäinen valintasi.

asetukset esitys Prosessoriohjain on melko turvallinen suorituskyvyn lisäys, koska se riippuu melkein kokonaan palvelimesi suorittimen rajasta. Mutta on olemassa muutamia sivuvaikutuksia (samalla kun suorittimen kello pysyy 100 %:ssa koko ajan) - kuten lämpö, ​​akun kesto (kannettava tietokone) ja muut. Tämä on kuitenkin todella nopein asetus prosessorisi.

Käytä pm=statica palvelimesi suorituskyvyn maksimoimiseksi

Asetus pm=static PHP-FPM:ssä riippuu suuresti siitä, kuinka paljon vapaata muistia palvelimella on. Periaatteessa, jos kärsit palvelimen muistin puutteesta, pm ondemand tai dynaaminen voivat olla parempia vaihtoehtoja. Toisaalta, jos sinulla on tarpeeksi vapaata muistia, voit välttää suurimman osan prosessinhallinnan kustannuksista asettamalla pm staattinen palvelimen enimmäiskapasiteettiin asti. Toisin sanoen, kun teet laskelmia, pm.static on asetettava enimmäismäärään PHP-FPM-prosesseja, jotka voidaan suorittaa. luomatta muistin tai välimuistin saatavuusongelmia; ei kuitenkaan niin korkea, että se ylikuormittaisi prosessoreita ja että siinä olisi joukko vireillä olevia PHP-FPM-toimintoja.

Yllä olevassa kuvakaappauksessa tälle palvelimelle on asetettu pm = static ja pm.max_children = 100, mikä käyttää enintään noin 10 Gt asennetusta 32 Gt:sta. Huomaa korostetut sarakkeet, jotka puhuvat puolestaan. Tämän kuvakaappauksen ajankohtana aktiivisia käyttäjiä oli noin 200 (viimeisen 60 sekunnin aikana). Tällä käyttäjätasolla noin 70 % PHP-FPM:n lapsiprosesseista on edelleen käyttämättömänä. Tämä tarkoittaa, että PHP-FPM on määritetty käyttämään aina palvelimesi resurssien maksimikapasiteettia nykyisestä liikenteestä riippumatta. Käyttämättömät prosessit pysyvät "online-tilassa" odottamassa liikennepursketta, joka vastaa välittömästi odottamisen sijaan P.M. kun se luo lapsiprosesseja, ja sitten se tappaa ne pm.process_idle_timeout vanhentuessa. Asetuksissani pm.max_requests on asetettu erittäin korkeaksi, koska tämä on tuotantopalvelin, jolla ei pitäisi olla muistivuotoja PHP:ssä. Voit käyttää pm.max_requests = 0 staattisessa tilassa, jos sinulla on 110 % luottamus nykyisiin ja tuleviin PHP-skripteihisi. On kuitenkin suositeltavaa suorittaa skriptit uudelleen aika ajoin. Aseta pyyntöjen määrä ennen uudelleenkäynnistystä korkeimpaan arvoon välttääksesi PM-ylimääräiset kustannukset. Esimerkiksi vähintään pm.max_requests = 1000... perustuu pm.max_children ja pyyntöjen määrään sekunnissa.

Kuvakaappaus käyttää Linux top . Kaikki prosessit eivät näy tässä, vaan vain osa, joka sopii pääteikkunaan. Meidän tapauksessamme lajiteltu %CPU:n mukaan (prosessorin kulutus). Nähdäksesi kaikki 100 PHP-FPM-prosessia voit käyttää jotain tällaista:

Top -bn1 | grep php-fpm

Milloin käyttää pm ondemand ja dynaaminen

Dynaamista tilaa käytettäessä saatat kohdata seuraavanlaisia ​​virheitä:

VAROITUS: näyttää kiireiseltä (sinun on ehkä lisättävä pm.start_servers- tai pm.min/max_spare_servers), synnyttää 32 lasta, on 4 käyttämätöntä ja yhteensä 59 lasta

Voit yrittää suurentaa/muuttaa asetuksia ja nähdä silti saman virheen. Samanlainen tilanne on kuvattu tässä Serverfaultin kysymyksessä. Tässä tapauksessa pm.min oli liian pieni, ja koska liikenne vaihtelee suuresti, dynaamista tilaa on melko vaikea konfiguroida oikein. Yleiset neuvot: käytä ondemand , kuten samassa kysymyksessä neuvottiin. Vielä pahempaa on kuitenkin se, että ondemand lopettaa tyhjäkäynnillä olevat prosessit nollaan, kun liikennettä on vähän, jonka jälkeen saat niin paljon yleiskustannuksia kuin liikenne hyppää. Ellet tietenkään aseta aikakatkaisua erittäin korkeaksi. Tässä tapauksessa sinun tarvitsee vain käyttää pm = static + high pm.max_requests .

Tästä huolimatta dynaaminen tila ja erityisesti ondemand voi säästää, kun sinulla on useita PHP-FPM-pooleja. Esimerkiksi kun ylläpidetään useita cPanel-tilejä tai useita sivustoja eri poolien alla. Minulla on palvelin, jossa on esimerkiksi 100+ cPanel-tiliä ja noin 200+ domainia, ja staattisen tai edes dynaamisen tilan olisi mahdotonta ylläpitää hyvää suorituskykyä. Ja vain ondemand-tila tekee tämän hyvin, koska yli kahdella kolmasosalla verkkosivustoista on vähän liikennettä, ja ondemandilla tämä tarkoittaa, että kaikki "lapset" valmistuvat, mikä säästää tonnia palvelinmuistia! Onneksi cPanel-kehittäjät ymmärsivät tämän ja nyt oletuksena on ondemand . Aikaisemmin alkaen dynaaminen oletustilassa, PHP-FPM:n käyttö jaetuilla palvelimilla ei ollut vaihtoehto. Monet ovat käyttäneet suPHP, koska dynaaminen tila kulutti muistia, vaikka PHP-FPM Poolit olivat käyttämättömänä. Todennäköisesti, jos sinulla on hyvä liikenne, sinua ei isännöidä palvelimella, jossa on suuri määrä PHP-FPM-pooleja (jaettu hosting).

Johtopäätös

Mitä tulee PHP-FPM:ään, kun alat saada vakavaa liikennettä, ondemand ja dynaamiset tilat voivat rajoittaa suorituskykyäsi luontaisen yleiskustannusten vuoksi. Tutki järjestelmääsi ja aseta prosessien määrä korkeimmalle, jonka palvelimesi pystyy käsittelemään. Aloita pm.max_children-asetuksilla, jotka perustuvat dynaamisten tai ondemand-tilojen maksimikäyttöön, ja lisää sitten siihen pisteeseen, jossa muistia ja prosessoria ei rajoiteta. Huomaat, että pm = static , koska pidät kaiken muistissa, liikennepiikit vaikuttavat vähemmän prosessoripiikeihin ajan myötä, ja kuormituksen ja kuormituksen keskiarvot tulevat tasaisemmiksi. PHP-FPM-prosessisi keskimääräinen koko riippuu tietystä verkkopalvelimesta, joka vaatii manuaalisen konfiguroinnin, minkä vuoksi automaattiset tilat ovat dynaaminen Ja tarpeen vaatiessa- ovat suositumpia suosituksia. Toivottavasti tämä oli hyödyllinen artikkeli.