[vpsFree.cz: community-list] {Disarmed} Re: php pro nginx high load

[Tomas Srnka]

Ahoj,

len v skratke:

- GlusterFS pre PHP je totalna smrt, zdvihne ti latencie na nacitanie 1
suboru cca na 100x (ak nemas IB, potom len asi 10x :)). Idealne uprav
aplikaciu tak aby si zapisoval len data do urcitych adresarov a tie mal
pripojene z dakeho NFS storage a PHP subory mal ulozene lokalne.
Samozrejmostou je potom OPCache.  Co sa tyka dvojho php-fpm configu - pre
pool si nastav pm=static, a nechaj pocet vlakien na urovni poctu CPU. Ak
mas na tom istom serveri aj mysql a nginx tak nejakym rozumny pomerom si to
predel medzi tie sluzby. Preco mas pm.max_requests na tak nizkej hodnote?
Idealne by to malo byt v desiatkach tisic. Kam ukladas sessions? Ak do
files, presun ich do redis / memcached. Este mi napada, neviem aku mas
verziu PHP, ale skus pouzivat vzdy najnovsiu, momentalne teda 5.6.x, do
PHP7 by som sa zatial nepustal (vysla vcera :).

- MySQL  M-M ti pomoze iba v pripade ak riesis read-only intesive + mas
napisanu appku na to, aby dokazala fungovat v takomto mode. Treba mysliet
na to, ze replikacia je by design asynchronna (mas sice semi-sync plugin),
ale dost mozne mozes pri velkej zatazi mat ine data na server A ako na
serveri B. Lepsi napad je pouzit build-in galera cluster, ale treba min 3
nody.. Stale vsak skalujes iba read-operacie.

- DNS round-robin funguje pre rozlozenie zataze, ale nefunguje dobre ako
fail over, tj. ak ti umrie jeden server, tak ti dost mozno nacita iba 50%
contentu (kazdy druhy obrazok atd.), druha vec je, ze kopec providerov
cachuje DNS.

2015-12-02 8:25 GMT+01:00 Branislav Viest <info at branoviest.com>:

> Ahoj,
>
> mám tady jeden server kde je cca 35k lidí za vteřinu. Běží tu nginx + php
> fpm a mysql db. V nginxu jsem rozjel microcache, což hodně ulevilo zátěži
> serveru. Nicméně, mám problém s PHPkem. FPM běží přes TCP (zkoušel jsem i
> unix socket nicméně bylo to pomalější a docházelo ke stejnému problému).
> Dle error logu dochází k těmto chybám:
>
> 2015/12/01 23:26:56 [error] 27043#0: *122476 recv() failed (104:
> Connection reset by peer) while reading response header from upstream,
> client: 188.114.98.51, server: xxx request: "GET /xxx/xxxx/xxx HTTP/1.1",
> upstream: "fastcgi://127.0.0.1:9000", host: "xxxx", referrer: "
> http://xxxxx"
> 2015/12/01 23:26:56 [error] 27032#0: *124368 recv() failed (104:
> Connection reset by peer) while reading response header from upstream,
> client: 188.114.99.50, server: xxxxxx, request: "GET /xxxxx/xxxxx
> HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "xxxxx", referrer:
> "xxxxx"
>
> a sype to tam docela drsně. Jak vypnu kešování v nginxu load vyskočí,
> třeba i na 500, těch chyb PHPka je méně ale jsou tam pořád.
>
> Konfigurace FPM pro pool toho webu je:
>
> [web1]
>
> listen = 127.0.0.1:9000
> listen.allowed_clients = 127.0.0.1
> listen.owner = web1
> listen.group = client0
> listen.mode = 0660
> listen.backlog = 65536
>
> user = web1
> group = client0
>
> request_slowlog_timeout = 5s
> slowlog = /var/log/php-fpm/slowlog-web1.log
>
> pm = dynamic
> pm.max_children = 7000
> pm.start_servers = 4000
> pm.min_spare_servers = 2000
> pm.max_spare_servers = 4000
> pm.max_requests = 100
>
> request_terminate_timeout = 60s
> rlimit_files = 500000
> rlimit_core = unlimited
> catch_workers_output = yes
>
> pm.status_path = /php-status
>
> chdir = /
>
> + openbasedir, sessions save path. atp.
>
> S těma hodnotama jsem se zkoušel různě hrát, nicméně to k vyřešení tohoto
> problému nepomohlo. Zkoušel jsem upravit i nějaké parametry jádra (local
> port range, tcp ack timeouty atp.) ale výsledek stejný. Dělá to i u unix
> socketu, což je mi právě zvláštní. Nginx konfigurace je:
> user www-data;
> worker_processes 80;
> pid /run/nginx.pid;
> # set open fd limit to 50000
> worker_rlimit_nofile 100000;
>
> events {
> worker_connections 1024;
> multi_accept on;
> use epoll;
> }
>
> ve vhostu nic zvlastniho, jenom pro php:
>
> fastcgi_split_path_info ^(.+\.php)(/.+)$;
> fastcgi_param SCRIPT_FILENAME $document_root/$fastcgi_script_name;
> include /etc/nginx/fastcgi_params;
> fastcgi_pass 127.0.0.1:9000;
> fastcgi_index index.php;
> fastcgi_intercept_errors on;
> fastcgi_read_timeout 4m;
>
> Dnes bude k tomuto server nový, pro rozdělení zátěže, ale jako fakt nevím
> jestli to má smysl ve stejné konfiguraci, kvůli těm php chybám. Nenapadá
> Vás kluci, co s tím? Nebo případně návrh řešení, kterým bych nahradil
> tohle, při dvou serverech ? Přemýšlím nad MySQL M - M replikací, v DNS
> round robin a GlusterFS pro data. Ale to phpko mi nedá spát. A dnes večer
> to už další nápor asi nedá.
>
> Díky za rady a konzultace.
>
> S pozdravem
> Branislav Viest
>
> _______________________________________________
> Community-list mailing list
> Community-list at lists.vpsfree.cz
> http://lists.vpsfree.cz/listinfo/community-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.vpsfree.cz/pipermail/community-list/attachments/20151202/306888e2/attachment-0002.html>