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@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://MailScanner warning: numerical links are often malicious: 127.0.0.1:9000", host: "xxxx", referrer: "MailScanner has detected a possible fraud attempt from "xxxxx" claiming to be 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://MailScanner warning: numerical links are often malicious: 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 = MailScanner warning: numerical links are often malicious: 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 MailScanner warning: numerical links are often malicious: 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@lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list