On 02 Dec 2015, at 10:36, skrivy(a)skrivy.net wrote: Proti tomu se musim ohradit. Hostuju weby z alexa 15 000 a se spravnou konfiguraci a slusne napsanou aplikaci s tim neni jedinej problem. -- Sent from my Nokia N9 On 02.12.2015 10:23 Zlatko Fedor wrote: Ahoj. Pred par mesiacmi som mal podobny problem. Skusil som naozaj vsetko. Milion nastaveni no stale to robilo to iste s mensim alebo vecsim opakovanim. Skusal som unix sockery, tcp sokety, rozne cache, dynamic/static childs proste setko co som nasiel. Precital som celu dokumentaciu takze som presne vedel co robim. Po pol roku som to vzdal a prepisal vsetko do node.js. Podla mojho nazoru je PHP-FPM uplne zabagovane. Predtym som pouzival apache s php a nemal som jediny problem. Ale asi ako ty aj ja som narazil vtedy na jeho limity. Viem ze som ti asi nepomohol len ta chcem pripravit aj na moznost ze PHP FPM nieje kvalitny softver. S pozdravom Zlatko Fedor _______________________________________________ Community-list mailing list Community-list(a)lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

To je jako zavolat doktorovi, ze ti je spatne. :) Na to neni obecna odpoved. Vsechny aplikace jsou jine a potrebuji trochu neco jineho. Jak uz bylo zmineno - opcode cache, vyhnout se zamkum na memcache, atd. S temi procesy bych byl opatrny - php casto ceka na vnejsi zdroje, takze se jich tam da spustit vic. Monitoring delam by default scenarem v zabbixu, aby byla nejaka dlouhodoba data + samozrejne nginx server status a php status. U problemovych webu sbirame i data z aplikacni urovne - tzn. jak dlouho trvaji volani do ..., sql dotazy, http kody a vsechno to sypu do grafu, abych videl dlouhodobe zmeny. -- Sent from my Nokia N9 On 02.12.2015 11:03 Zlatko Fedor wrote: Velmi rad pocujem ze niekomu to funguje spravne. Vies prosim napisat viac informacii pripadne prilozit svoj config? Rad si aspon spatne precitam co som robil zle. Nasledujucu otazku si prosim neber osobne: Monitoruju tvoje weby uplne kazdy vypadok a chybu alebo sa len spoliehas na to ze to ide ked napises stranku do browsera pripadne na pingdom ktoremu vela veci ujde. Dakujem za odpoved On 02 Dec 2015, at 10:36, skrivy(a)skrivy.net wrote: Proti tomu se musim ohradit. Hostuju weby z alexa 15 000 a se spravnou konfiguraci a slusne napsanou aplikaci s tim neni jedinej problem. -- Sent from my Nokia N9 On 02.12.2015 10:23 Zlatko Fedor wrote: Ahoj. Pred par mesiacmi som mal podobny problem. Skusil som naozaj vsetko. Milion nastaveni no stale to robilo to iste s mensim alebo vecsim opakovanim. Skusal som unix sockery, tcp sokety, rozne cache, dynamic/static childs proste setko co som nasiel. Precital som celu dokumentaciu takze som presne vedel co robim. Po pol roku som to vzdal a prepisal vsetko do node.js. Podla mojho nazoru je PHP-FPM uplne zabagovane. Predtym som pouzival apache s php a nemal som jediny problem. Ale asi ako ty aj ja som narazil vtedy na jeho limity. Viem ze som ti asi nepomohol len ta chcem pripravit aj na moznost ze PHP FPM nieje kvalitny softver. S pozdravom Zlatko Fedor On 02 Dec 2015, at 09:56, Branislav Viest <info(a)branoviest.com> wrote: tohle je vytezek z php-fpm logu [02-Dec-2015 09:54:39.867720] WARNING: pid 5043, fpm_request_check_timed_out(), line 269: [pool web1] child 24945, script 'xxxwww//index.php' (request: "GET /index.php") executing too slow (5.799737 sec), logging # to je jasny [02-Dec-2015 09:54:39.867981] DEBUG: pid 5043, fpm_got_signal(), line 76: received SIGCHLD [02-Dec-2015 09:54:39.868499] NOTICE: pid 5043, fpm_children_bury(), line 227: child 24945 stopped for tracing [02-Dec-2015 09:54:39.868508] NOTICE: pid 5043, fpm_php_trace(), line 144: about to trace 24945 [02-Dec-2015 09:54:39.868731] NOTICE: pid 5043, fpm_php_trace(), line 172: finished trace of 24945 [02-Dec-2015 09:54:39.869145] NOTICE: pid 5043, fpm_children_bury(), line 227: child 28359 stopped for tracing [02-Dec-2015 09:54:39.869161] NOTICE: pid 5043, fpm_php_trace(), line 144: about to trace 28359 [02-Dec-2015 09:54:39.869415] NOTICE: pid 5043, fpm_php_trace(), line 172: finished trace of 28359 [02-Dec-2015 09:54:39.869893] NOTICE: pid 5043, fpm_children_bury(), line 227: child 33445 stopped for tracing [02-Dec-2015 09:54:39.869904] NOTICE: pid 5043, fpm_php_trace(), line 144: about to trace 33445 [02-Dec-2015 09:54:39.870101] NOTICE: pid 5043, fpm_php_trace(), line 172: finished trace of 33445 [02-Dec-2015 09:54:39.870602] NOTICE: pid 5043, fpm_children_bury(), line 227: child 36581 stopped for tracing [02-Dec-2015 09:54:39.870615] NOTICE: pid 5043, fpm_php_trace(), line 144: about to trace 36581 [02-Dec-2015 09:54:39.870884] NOTICE: pid 5043, fpm_php_trace(), line 172: finished trace of 36581 [02-Dec-2015 09:54:39.871187] NOTICE: pid 5043, fpm_children_bury(), line 227: child 37001 stopped for tracing [02-Dec-2015 09:54:39.871195] NOTICE: pid 5043, fpm_php_trace(), line 144: about to trace 37001 [02-Dec-2015 09:54:39.871460] NOTICE: pid 5043, fpm_php_trace(), line 172: finished trace of 37001 [02-Dec-2015 09:54:39.872162] DEBUG: pid 5043, fpm_got_signal(), line 76: received SIGCHLD [02-Dec-2015 09:54:39.872582] DEBUG: pid 5043, fpm_got_signal(), line 76: received SIGCHLD [02-Dec-2015 09:54:39.872950] DEBUG: pid 5043, fpm_got_signal(), line 76: received SIGCHLD [02-Dec-2015 09:54:39.873295] DEBUG: pid 5043, fpm_got_signal(), line 76: received SIGCHLD [02-Dec-2015 09:54:39.873616] DEBUG: pid 5043, fpm_event_loop(), line 424: event module triggered 1 events S pozdravem Branislav Viest ------------------------------ *Od: *"Věroslav Kaplan" <veros.kaplan(a)gmail.com> *Komu: *"vpsFree.cz Community list" <community-list(a)lists.vpsfree.cz> *Odoslané: *streda, 2. december 2015 9:48:22 *Predmet: *{Disarmed} [vpsFree.cz: community-list] {Disarmed} Re: php pro nginx high load Ahoj, Tohle vypadá, že PHP-FPM z nějakého důvodu zavře to fcgi spojení. Dokážeš vytáhnout nějaké podezřelé logy z toho PHP-FPM a zkusit uhodnout, proč to dělá ? --Věroš Kaplan http://veroskaplan.cz/ Školíme Ansible: http://ansible.cz/ 2015-12-02 8:25 GMT+01:00 Branislav Viest <info(a)branoviest.com>om>: -- --V.Kaplan _______________________________________________ Community-list mailing list Community-list(a)lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list _______________________________________________ Community-list mailing list Community-list(a)lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list _______________________________________________ Community-list mailing list Community-list(a)lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list _______________________________________________ Community-list mailing list Community-list(a)lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

Tohle jsem řešil nedávno taky. Uprav počet pm.max_requests na cca 10x až 100x vyšší číslo, nebo ho nastav na nulu pokud víš, že ti v aplikaci neleakuje paměť. Fpm se chová tak, že po splnění limitu requestů ten child zabije, ale nginx se na něj zkusí stejně připojit a skončí to touhle chybou. Tomáš st 2. 12. 2015 v 11:21 odesílatel <skrivy(a)skrivy.net> napsal: >To je jako zavolat doktorovi, ze ti je spatne. :) Na to neni obecna >odpoved. Vsechny aplikace jsou jine a potrebuji trochu neco jineho. > > > >Jak uz bylo zmineno - opcode cache, vyhnout se zamkum na memcache, >atd. S temi procesy bych byl opatrny - php casto ceka na vnejsi >zdroje, takze se jich tam da spustit vic. > > > >Monitoring delam by default scenarem v zabbixu, aby byla nejaka >dlouhodoba data + samozrejne nginx server status a php status. > > > >U problemovych webu sbirame i data z aplikacni urovne - tzn. jak >dlouho trvaji volani do ..., sql dotazy, http kody a vsechno to sypu >do grafu, abych videl dlouhodobe zmeny. > > > >-- > > > >Sent from my Nokia N9 > > > > >On 02.12.2015 11:03 Zlatko Fedor wrote: > >Velmi rad pocujem ze niekomu to funguje spravne. >Vies prosim napisat viac informacii pripadne prilozit svoj config? >Rad si aspon spatne precitam co som robil zle. > >Nasledujucu otazku si prosim neber osobne: >Monitoruju tvoje weby uplne kazdy vypadok a chybu alebo sa len >spoliehas na to ze to ide ked napises stranku do browsera pripadne na >pingdom ktoremu vela veci ujde. > >Dakujem za odpoved > > > >>On 02 Dec 2015, at 10:36, skrivy(a)skrivy.net wrote: >> >>Proti tomu se musim ohradit. >> >>Hostuju weby z alexa 15 000 a se spravnou konfiguraci a slusne >>napsanou aplikaci s tim neni jedinej problem. >> >> >>-- >> >> >>Sent from my Nokia N9 >> >> >> >>On 02.12.2015 10:23 Zlatko Fedor wrote: >> >>Ahoj. >> >>Pred par mesiacmi som mal podobny problem. >>Skusil som naozaj vsetko. Milion nastaveni no stale to robilo to iste >>s mensim alebo vecsim opakovanim. >>Skusal som unix sockery, tcp sokety, rozne cache, dynamic/static >>childs proste setko co som nasiel. Precital som celu dokumentaciu >>takze som presne vedel co robim. >>Po pol roku som to vzdal a prepisal vsetko do node.js. Podla mojho >>nazoru je PHP-FPM uplne zabagovane. >>Predtym som pouzival apache s php a nemal som jediny problem. Ale asi >>ako ty aj ja som narazil vtedy na jeho limity. >> >>Viem ze som ti asi nepomohol len ta chcem pripravit aj na moznost ze >>PHP FPM nieje kvalitny softver. >> >>S pozdravom >>Zlatko Fedor >> >>>On 02 Dec 2015, at 09:56, Branislav Viest <info(a)branoviest.com> >>>wrote: >>> >>>tohle je vytezek z php-fpm logu >>> >>>[02-Dec-2015 09:54:39.867720] WARNING: pid 5043, >>>fpm_request_check_timed_out(), line 269: [pool web1] child 24945, >>>script 'xxxwww//index.php' (request: "GET /index.php") executing too >>>slow (5.799737 sec), logging # to je jasny >>>[02-Dec-2015 09:54:39.867981] DEBUG: pid 5043, fpm_got_signal(), >>>line 76: received SIGCHLD >>>[02-Dec-2015 09:54:39.868499] NOTICE: pid 5043, fpm_children_bury(), >>>line 227: child 24945 stopped for tracing >>>[02-Dec-2015 09:54:39.868508] NOTICE: pid 5043, fpm_php_trace(), >>>line 144: about to trace 24945 >>>[02-Dec-2015 09:54:39.868731] NOTICE: pid 5043, fpm_php_trace(), >>>line 172: finished trace of 24945 >>>[02-Dec-2015 09:54:39.869145] NOTICE: pid 5043, fpm_children_bury(), >>>line 227: child 28359 stopped for tracing >>>[02-Dec-2015 09:54:39.869161] NOTICE: pid 5043, fpm_php_trace(), >>>line 144: about to trace 28359 >>>[02-Dec-2015 09:54:39.869415] NOTICE: pid 5043, fpm_php_trace(), >>>line 172: finished trace of 28359 >>>[02-Dec-2015 09:54:39.869893] NOTICE: pid 5043, fpm_children_bury(), >>>line 227: child 33445 stopped for tracing >>>[02-Dec-2015 09:54:39.869904] NOTICE: pid 5043, fpm_php_trace(), >>>line 144: about to trace 33445 >>>[02-Dec-2015 09:54:39.870101] NOTICE: pid 5043, fpm_php_trace(), >>>line 172: finished trace of 33445 >>>[02-Dec-2015 09:54:39.870602] NOTICE: pid 5043, fpm_children_bury(), >>>line 227: child 36581 stopped for tracing >>>[02-Dec-2015 09:54:39.870615] NOTICE: pid 5043, fpm_php_trace(), >>>line 144: about to trace 36581 >>>[02-Dec-2015 09:54:39.870884] NOTICE: pid 5043, fpm_php_trace(), >>>line 172: finished trace of 36581 >>>[02-Dec-2015 09:54:39.871187] NOTICE: pid 5043, fpm_children_bury(), >>>line 227: child 37001 stopped for tracing >>>[02-Dec-2015 09:54:39.871195] NOTICE: pid 5043, fpm_php_trace(), >>>line 144: about to trace 37001 >>>[02-Dec-2015 09:54:39.871460] NOTICE: pid 5043, fpm_php_trace(), >>>line 172: finished trace of 37001 >>>[02-Dec-2015 09:54:39.872162] DEBUG: pid 5043, fpm_got_signal(), >>>line 76: received SIGCHLD >>>[02-Dec-2015 09:54:39.872582] DEBUG: pid 5043, fpm_got_signal(), >>>line 76: received SIGCHLD >>>[02-Dec-2015 09:54:39.872950] DEBUG: pid 5043, fpm_got_signal(), >>>line 76: received SIGCHLD >>>[02-Dec-2015 09:54:39.873295] DEBUG: pid 5043, fpm_got_signal(), >>>line 76: received SIGCHLD >>>[02-Dec-2015 09:54:39.873616] DEBUG: pid 5043, fpm_event_loop(), >>>line 424: event module triggered 1 events >>> >>>S pozdravem >>>Branislav Viest >>> >>> >>>-------------------------------------------------------------------------------- >>>Od: "Věroslav Kaplan" <veros.kaplan(a)gmail.com> >>>Komu: "vpsFree.cz Community list" <community-list(a)lists.vpsfree.cz> >>>Odoslané: streda, 2. december 2015 9:48:22 >>>Predmet: {Disarmed} [vpsFree.cz: community-list] {Disarmed} Re: php >>>pro nginx high load >>> >>>Ahoj, >>> >>>Tohle vypadá, že PHP-FPM z nějakého důvodu zavře to fcgi spojení. >>>Dokážeš vytáhnout nějaké podezřelé logy z toho PHP-FPM a zkusit >>>uhodnout, proč to dělá ? >>> >>>--Věroš Kaplan >>>http://veroskaplan.cz/ >>>Školíme Ansible: http://ansible.cz/ >>> >>>2015-12-02 8:25 GMT+01:00 Branislav Viest <info(a)branoviest.com>om>: >>>>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 has >>>>detected a possible fraud attempt from "127.0.0.1:9000" claiming to >>>>beMailScanner 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 has >>>>detected a possible fraud attempt from "127.0.0.1:9000" claiming to >>>>beMailScanner 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 has detected a possible fraud attempt from >>>>"127.0.0.1:9000" claiming to beMailScanner 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 has detected a possible fraud attempt from >>>>"127.0.0.1:9000" claiming to beMailScanner 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(a)lists.vpsfree.cz >>>>http://lists.vpsfree.cz/listinfo/community-list >>>> >>> >>> >>> >>>-- >>>--V.Kaplan >>> >>>_______________________________________________ >>>Community-list mailing list >>>Community-list(a)lists.vpsfree.cz >>>http://lists.vpsfree.cz/listinfo/community-list >>>_______________________________________________ >>>Community-list mailing list >>>Community-list(a)lists.vpsfree.cz >>>http://lists.vpsfree.cz/listinfo/community-list >> >> >>_______________________________________________ >>Community-list mailing list >>Community-list(a)lists.vpsfree.cz >>http://lists.vpsfree.cz/listinfo/community-list > > >_______________________________________________ >Community-list mailing list >Community-list(a)lists.vpsfree.cz >http://lists.vpsfree.cz/listinfo/community-list

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.

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

Jenom pár poznámek Tohle dává smysl, ale taky záleží na tom, co to PHP dělá. Jakmile budeš mít skript, který na něco čeká (HTTP požadavky na nějakou platební bránu, stahování dat z facebooku apod.), bude se ti CPU flákat. Samozřejmě dělat tyhle (potenciálně) dlouhotrvající věci synchronně je dost často blbost, ale programátoři to dělají i tak. Já myslel, že master-master je read/write? Nestačilo by pro read-only master-slave? (I když přiznávám, že u MySQL jsem replikaci viděl jenom z rychlíku a stačilo mi to) Prohlížeče AFAIK (myslím, že to tu psal Pavel Šnajdr) zkusí druhou IP, když se na té první nedoptají. A většina používá HTTP keep-alive, takže by se obsah přes to jedno spojení měl stáhnout všechen. J. P.S.: Ví někdo, kde se bere to {disarmed} v subjektech? _______________________________________________ Community-list mailing list Community-list(a)lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list