PHP5-FPM kérdések

 ( gkaroly | 2016. február 6., szombat - 13:41 )

Sziasztok!

Adott egy gép, ami webszerverként üzemel. A gépen Debian Jessie van, Apache2+mod-php -vel.

Ezen a gépen több weblap fut, ebből 3 kritikus. Értsd: ha az oldal nem jön be, összedől a világ. :)

Fontos lenne, hogy weblaponként tudjam szabályozni a PHP memory_limit-et és a post_max_size értéket. A gond az, hogyha bármelyik vhostba 192M-t írok be, akkor minden oldal 192M memory limit-et kap, illetve a vhost-okban szereplő legmagasabb értéket.

Arra rájöttem, hogy a megoldás a php5-fpm -re való áttérés. Kerestem mindenféle howto-t, de sajnos hiába üzemeltem be (vért izzadva), a felállás ugyanaz volt, mint mod-php -vel. Persze az egészet nulláról csináltam, de mégis, valamiért az /etc/php5/apache2/php.ini -ből vette az értéket.

Erre keresnék valami megoldást, ha van. Akár egy link is elég, igaz, én már széttúrtam a Google-t, de nem sok sikerrel jártam.

Kezdetnek van 1 próba VPS-em, amin tudok szórakozni a dologgal, úgyhogy minden ötletet szívesen fogadok.
Köszönöm előre is!

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

php-fpm, kell minden site-nak sajat php-fpm. Ahogy regen minden site-hoz futott az fcgid.

Fedora 23, Thinkpad x220

Igen, ezt tudom. Ezt meg is tudom csinálni, viszont maga a weboldal továbbra is a központi helyről veszi a php.ini értékeket és ez gáz.

Erről valami howto-t köszönettel vennék.

--
-- GKPortál Blog
Tégy Jót!®
Legyen neked is Dropbox tárhelyed! :)

php-fpm konfigokban tudsz megadni egyedi (admin) ertekeket amik adott instance-okra jellemzok, ezzel felulbiralva a global php.ini-t
Pl: php_admin_value[memory_limit] = 32M
http://php.net/manual/en/install.fpm.configuration.php
de sok egyeb dolgot lehet/erdemes egyedileg modositani.

Egyebkent javaslom inkabb 2.4-es apache-ot inkabb ha mar fpm.

Az irreleváns onnantól, hogy külső futtatónak adod át a php-t. Ha a PHP FPM-ezel, akkor minden process csoportja lehet külön juzerrel is akár. Bónuszként az Apache oldalon worker MPM-et is be lehet lőni.

én a nyitó helyében ezt a megoldást preferálnám, ha már a php-fpm-et feltette. poolonként különböző érték, és csókolom. egyszerű, de nagyszerű.

Ez nem csak FPM-el orvosolható!
Berakhatod .htaccess-be is, ha engedélyezve van az AllowOverride:
php_value memory_limit 128M

vagy apache config-ba:

[...]
php_value memory_limit 192M
[...]

S.

elvileg a virtualhostonkenti php_admin_value segedelmevel torteno beallitasnak ervenyesnek kellene lennie

nem irtal peldakonfigot, igy van belove ?

php_admin_value memory_limit 192M
php_admin_value post_max_size 192M

php-fpm eseten a [PATH=] reszben valami ilyesmi :

[PATH=/home/www/MyAdmin/weblap]
post_max_size = 40M

+1

t

Csalodtam benned. Legalabb az ekezeteket meg a kezdo nagybetuket kijavithattad volna.. :)

--
Is that a banana in your pocket, or are you just happy to see me?
Neither, it's my new iPhone.

szerintem figyeli, hogy 10+ eve ekezet nelkul irok, ergo a 'javithatatlan' kategoriaba tartozom.

Biztos en nem ertek hozza, de ha mar ennyire kritikus, akkor kulon gepre vm-ekbe/dockerekbe teheted oket redundansan, elszeparalva oket egymastol. Mar csak egy (pl. round-robin) utemezo kell ele. A VM-ek eroforrasat meg gondolom le lehet limitalni, hogy a masiket ne egye meg.

--
Is that a banana in your pocket, or are you just happy to see me?
Neither, it's my new iPhone.

Hosszútávon ez a cél. Csak sajnos jelenleg keret nincs rá.

--
-- GKPortál Blog
Tégy Jót!®
Legyen neked is Dropbox tárhelyed! :)

1. Ha kesobb ez lesz a cel, most is atalakithatod ilyenre, akkor kesobb csak klonozni kell azt a par vm-et/containert.
2. Gondolom ezek valamilyen alapitvanyi/nonprofit oldalak. Van par hosting ceg, akik ilyenre eleg jutanyos aron/ingyen adnak helyet. Nincs rola listam, mert nem foglalkoztam az utobbi idoben alapitvanyokkal, de pl. Gyumolcstarhely remlik, hogy ilyen.

--
Is that a banana in your pocket, or are you just happy to see me?
Neither, it's my new iPhone.

1. Jelenleg OpenVZ alapú VPS-en vannak a cuccok, plusz többféle biztonsági megoldás is be van iktatva (titkosítás, ilyesmik), ezért nem játszik a 2. pont.

Továbbá az OpenVZ nem hiszem, hogy ennyire elszeparálható, mint ahogy írta Nyosigomboc. (De ha mégis, akkor utánajárok, hogyan.)

--
-- GKPortál Blog
Tégy Jót!®
Legyen neked is Dropbox tárhelyed! :)

A docker elvileg csak egy okosabb chroot, nem hiszem, hogy VM-en ne menne.
Amugy nem szeretem az OpenVZ-t, mert a memoriat nem kapod meg dedikaltan, es akkor is kifogyhatsz belole, ha elvileg meg lenne. A tobbivel elvileg nincs ilyen gond.

--
Is that a banana in your pocket, or are you just happy to see me?
Neither, it's my new iPhone.

+1
--
A legértékesebb idő a pillanat amelyben élsz.
https://sites.google.com/site/jupiter2005ster/

" A gond az, hogyha bármelyik vhostba 192M-t írok be, akkor minden oldal 192M memory limit-et kap, illetve a vhost-okban szereplő legmagasabb értéket."

Most nem próbálom ki, de ez nem tűnik logikus/normális működésnek! Az egyik virtualhost beállításai nem érvényesülhetnek egy másik vhostnál [is].

nyilvan hulyeseg.

t

Pedig de...

ha van:

a.conf
b.conf

a sites-available-ben, akkor a b.conf memory_limitje érvényesül az a.conf-ban is, mert a b.conf a legutolsó.

Nem tudom, ma újra fogom rakni az egész gépet, nincs jobb ötletem. :(

--
-- GKPortál Blog
Tégy Jót!®
Legyen neked is Dropbox tárhelyed! :)

Csak kérdezem, hogy miért baj, ha mindenütt magasabb a memóriahasználat az egységes php.ini-s beállítás miatt?

Normál esetben, ha 192M a limit, és a PHP-nak több kell, akkor elszáll, mert nem tudja lefoglalni amire szüksége van.
Gondolom nem az a cél ezzel a beállítással, hogy bizonyos oldalak ne működjenek, ha elfogy a memóriájuk.

Ha 192M a limit, de az alkalmazás elfut 50M használattal, akkor sem foglal többet, ha 192M a limit.

Sakk-matt,
KaTT :)

Ha elfut 50MB-al, de valószínüleg ezzel inkább a fontosalkalmazást szeretnék védeni.

Már előttem írtak ezekről, de hátha:

Ha ezt beállítod, akkor elvileg annak a vhost-nak a beállítását módosítod:

[VirtualHost *:80]
php_value memory_limit 50M
[/VirtualHost]

Bár a PHP kódban is felül lehet bírálni:

[?php

ini_set('memory_limit','999M');

Azt nem tudom fejből, hogy lehet-e korlátozni a kódban lévő limitet.
Htaccess-ben is lehet ilyen:

php_value memory_limit 999M

Szóval 3 helyen lehet.
És ha beraknád a korlátozandó site gyökerébe a .htaccess -be:

php_value memory_limit 50M

és kész?

Sakk-matt,
KaTT :)

Szerintem nem nekem akartad. :) Ráadásul a kérdésed az volt, hogy az általános 192M nekik miért nem jó. Én csak tippeltem. :)

Tényleg nem, hanem a téma gazdájának. Remélem, azért túléled! ;)

Sakk-matt,
KaTT :)

php_admin_value -vel tudod korlátozni.

pedig nem, csak gondolom kitorolted a config felet, pl azokat amik a kulon poolokat hoztak letre a.conf -ban illetve b.conf -ban.
Esetleg lehet hogy szimpatikusabb volt hogy egy socket nezett az apache-ra es nem ketto a kulonbozo configokban.

Szoval nem, nem es nem, hulyeseget beszelsz!


// Happy debugging, suckers
#define true (rand() > 10)

A megoldas nem feltetlen a php5-fpm. Nalam is apache2 es modphp van, de meg van oldva a dolog, tobb szaz userrel.

A vhost jogok suphp segitsegevel vannak elkulonitve, sajat joggal futnak, es sajat php.ini configja van minden vhostnak, igy teljesen kulonallo modon lehet szabalyozni a php beallitasokat.

suPHP_Engine On
suPHP_ConfigPath /etc/php5/vhosts/domainegy.hu/
suPHP_UserGroup domainegy vhostusers

____________________
http://szoftvervasarlas.co.hu - szoftverek legjobb áron

suPHP mindig is nagy kedvencem, azt favorizalom.

Fedora 23, Thinkpad x220

Ha kulon php.ini van vhost-onkent ahol megadod usert is akkor mivel jarsz jobban mintha php-fpm-ben lenne kulon konfigod domain-ekhez eltero userekkel es szukseg eseten eltero php konfiggal?

Ha jól rémlik a disabled_function csak php.ini ben tiltható. Valamint más a php-fpm és a suphp.

Fedora 23, Thinkpad x220

php-fpm-ben is megadhato:
php_admin_value[disable_functions]

Effektive miben mas, hol latni elonyet suphp-nak php-fpm-hez kepest?

Egyszerű mint a faék. Van pár plusz security feature, pl ha a fájlon 777 jog van nem futtatja, vagy ha nem az az owner ami meg van adva stb.
Nem kell futnia daemonnak ami akar elpusztulhat. Cserébe minden php hívás külön php-cgi process ami ugye lassabb. Valamit valamiért.

Fedora 23, Thinkpad x220

"Cserébe minden php hívás külön php-cgi process ami ugye lassabb"

Ezt hivatott javítani a fastcgi / fcgid?
Ott ugye vannak előre betöltött példányok. Előre meghatározható darabszámban.

Igen de mint mondtam, van pár plusz feature biztonság ügyileg, valamint nem kell futnia semmilyen daemonnak. Azaz ha 1 honlapot naponta 1 ember néz ne fusson fölöslegesen ott az fcgid, php-fpm stb. Plusz ha valami miatt kihalnak ezek akkor a site le is hal.

Szóval ez a tipikusan ha kell előveszem és fut, ha nem kell akkor nem, zavar vizet. Ez főleg ott lehet szempont ahol sok vhost van 1 masinán. Akinek meg kell a power bérel VPS-t :>

Fedora 23, Thinkpad x220

php-fpm pool-t lehet ondemand is konfiguralni, ha kell elinduljon modon es tudod korlatozni pool-onkent mennyi php futhat.

" Azaz ha 1 honlapot naponta 1 ember néz ne fusson fölöslegesen ott az fcgid"

Nem akartam részletekbe menően fogalmazni, de a meghatározott szám lehet 0 is.
Pl. min 0, max 5, idle time 600.
Ha senki nem nézi meg 5 percen belül, kilép. Ha jön egy látogató, igaz várnia kell pár másodpercet míg elindul, egy ritkán látogatott weboldalnál elnézzük.
Ezt a 0-s trükköt bevetve egy 600 weboldalas szervernél felére esett a RAM fogyasztás.

Akkor ha jól értem a php-fpm elindul max alapból 0 php-t indít el ? És ha szükséges akkor indít még processeket ?

Fedora 23, Thinkpad x220

Master process fut, ami inditgatja szukseges php child-okat, hogy ezekbol mennyit es milyen modon inditson pool-onkent konfiguralhatod, egyik verzioja ennek az ondemand.
"ondemand - the processes spawn on demand (when requested, as opposed to dynamic, where pm.start_servers are started when the service is started."

És virtuálhostonként/poolonként kell futnia a master process nek ezek szerint ?

Fedora 23, Thinkpad x220

1 master process van, nem pool-onkent 1 master.

A php-fpm-et rég használtam, én a fcgidről írtam.
Ott ilyeneket tudsz megadni a global configjában:

  IdleTimeout 30
  IdleScanInterval 120
  BusyTimeout 300
  BusyScanInterval 120
  ErrorScanInterval 3
  ZombieScanInterval 3
  ProcessLifeTime 300
  MaxProcessCount 600 # összesen az összes vhostot együttvéve mennyi futhat
  DefaultMaxClassProcessCount 5  # vhostonként max
  DefaultMinClassProcessCount 0  # vhostonként min
  MaxRequestsPerProcess 1000

Vhostonként elindul az adott vhost user ID-jával egy szülő processz. Ha kell, további gyerek folyamatokat hozhat létre, a wrapperben megadott számban. További szülő folyamatok indulhatnak el, ha kell.
Ha nincs látogatva az oldal, minden php-cgi processz bezáródik.
Ha min=0, apache restarnál több száz vhost mellett is 0 php-cgi fut az első pillanatokban.

Erre mondtam, hogy csak fut valami, ha van 200 vhost akkor 200 process. Valamint nekem régebben fcgid nem volt valami stabil. Ekkor jött a suphp, ott nem fut semmi, ha jön a kérés akkor indul a Vhost-onként konfigurált php-cgi verzió és kész. Nincsen "köztes" réteg, ami ha lehal plusz hibaforrás.

Fedora 23, Thinkpad x220

A felvetés jó. A suphp is egy modul, az fcgid is. Nem olyan, mint a php-fpm, hogy külön daemon, külön socket vagy port kapcsolódás.
Szerintem azzal, hogy vhostban megadom:
IfModule mod_fcgid.c
FCGIWrapper /var/www/fcgi/domained.hu/php5-fcgi-starter .php

Azzal a suphp modulhoz hasonlóan meghívja az fcgid modult és az apache könyvtárában lévő fcgid.conf alapján teszi a dolgát, limitál, ha kell.

Egy szemléletes kép .
Látszik, hogy csekély a futásidő és a wrapperen keresztül tetszőleges php értelmezőt lehet beállítani vhostonként.
Pofon egyszerű a használata.

Most direkt ránéztem egy üresjáratban lévő szerverre. Egy extra processz sem fut, csak az apache. Nincs php-cgi processz.
A suphp-t utoljára 2008 körül piszkáltam vegyes sikerekkel. Ránézek ha lesz időm, viszont fcgid nálam 2010 óta stabilan fut több száz vhosttal.

Szerintem forma forma, nekem a suphp jött be, elején voltak kis kényelmetlenségek, mert sok user megszokta hogyha irni akarnak file/könyvtárat akkor azt 777 joggal tehetik. Erre a suphp egy szép nagy 500 server errort dob.

Asszem annó 6.x környékén voltak teljesítmény probléma, de a 7.x ben ezeket megoldották.

Fedora 23, Thinkpad x220

Apache 2.4-el mar fcgid helyett inkabb apache fcgi proxy modul ajanlott, vhost-okban meg kell adni proxypass-al hogy php kereseket kuldje php-fpm pool-nak (akar kulon gepre is), erre kell figyelni hogy vhost-ban megadott proxy a php-hoz es hozzatartozo fpm pool-ban megadott eleres (socket vagy ip:port) egyezzen

kulon pooloknak lehetnek kulon beallitasai, az a tippem hogy ugy alltal at fpm-re, hogy csak egy poolt konfiguraltal be es az a pool szolgalta ki az osszes vhostot.
ha megmutatod a mostani configot konyebb megmondani, kertel howto-t, itt egy ami eleg szajbaragos: https://www.linode.com/docs/websites/apache/running-fastcgi-php-fpm-on-debian-7-with-apache

inditasz tobb apache-t es reverse proxyzol rajuk?

--
NetBSD - Simplicity is prerequisite for reliability

Szia!

Esetleg ez segíthet: Webszerver telepítése

Nem ide