PHP5-FPM kérdések

Linux-kezdő

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!

  • 4517 megtekintés

( _ventura_ v | 2016. 02. 06., szo – 13:01 )

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

Fedora 23, Thinkpad x220

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.

( sheepy v | 2016. 02. 06., szo – 14:08 )

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.

( hokuszpk | 2016. 02. 06., szo – 14:18 )

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

( Nyosigomboc v | 2016. 02. 06., szo – 16:20 )

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.

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.

( BehringerZoltan | 2016. 02. 06., szo – 23:46 )

" 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].

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 :)

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 :)

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)

( scottscott v | 2016. 02. 08., h – 09:21 )

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

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

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

" 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.

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."

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

( Replaced | 2016. 02. 09., k – 11:34 )

inditasz tobb apache-t es reverse proxyzol rajuk?

--
NetBSD - Simplicity is prerequisite for reliability