Občas nejsou přijata žádná data

Tomáš Jablonický

Ahoj,

už na více než třech projektech se mě začíná projevovat chyba: „Nebyla přijata žádná data“, tedy bílá smrt …

Původně jsem myslel, že to je chybou nastavení mého lokálního serveru, ale začíná se to projevovat i u kolegů a dokonce i na jedné z produkcí.

Používám Nette 2.1 a 2.2, Doctrine2, Kdyby, na všech těchto projektech.

Nesetkal se někdo z Vás s podobným chováním? Docela to snižuje produktivitu práce :-(

Ot@s

Co logy (aplikace i Apache). Nějaké nedávné upgrady (Nette)? Nedávno jsem přešel z 2.1.1 na 2.1.6 a musel jsem provést upgrade PHP z 5.4.14 na 5.4.35 (chovalo se to stejně, jak popisuješ).

xificurk

Tohle je na 99% segfault PHP…

Jiří Nápravník

Nemáš tam APC? Tohle mi způsobovalo APC a pomohl jen upgrade php a nahradit APC zend opcache…

Eda

Tohle se mi taky projevuje na jednom webu, už aspoň tak půl roku. Fičím na Nette 2.2. Ale mám pocit, že se to stává jen v Google Chrome, v jiných prohlížečích jsem to nezaznamenal.

Tomáš Jablonický

Zatím se mě to také děje v Google Chrome … to co jste navrhly výše prozkoumám.

Jiří Nápravník

Co vím, tak chrome to dělá tak, že dá vědět, že nebyla přijata žádná data, tuším, že to má ten ERR_EMPTY_RESPONSE ci jak. V IE se to projevovalo jako čistě bílá stránka…

jasin755

Tak přesně tento problém mám taky. Nepodařilo se mi ho doposud vyřešit, ale snad přispěju nějakými poznatky.

Vždy je to segmentation fault
5.5.8 to dělá o 80% častějí jak 5.5.9. Pokud použiji Nginx,PHP-FPM podívám se do logu, tak zjistím, že segvault je u 5.5.8 a 5.5.9 stejně častý. Jenom u 5.5.9 se požadavek zavola se stejnými parametry znova.
Při použití Apache a 5.5.9 je problém ještě méně častý. V logu ani Apache ani Nginx nic nenajdete pokud nedáte úroveň logování debug.
Prohlížeč by na to neměl mít vliv. Mě osobně to dělá Safari, ale když se podívám na WebmasterTools, tak robot na to naráží, taktéž poměrně často.
Myslel jsem si, že to způsobuje PHP bug #61106 a #66375, tak jsem upgradoval na Nette 2.2.6, ale bohužel problém přetvrvává.
S Nette ani Doctrine2 to pravděpodobně nemá nic společného. Dělá mi to i velmi starý projekt na který se x let nešáhlo a není psaný ani objektově a fungoval bez problému dokud se neudělal upgrade na PHP 5.5.8 nebo 5.5.9 (nižší verze 5.5.x jsem nezkoušel).
Rozšíření které používám je open_ssl, opcache, memcache, memcached, gettext zbytek standard PHPka. Průník rozšíření které používájí jednotlivé projekty je memcache a opcache

Přidávám výpis logu Nginxu:

.....
2014/09/19 10:30:35 [debug] 27983#0: *110908 posix_memalign: 00007F110C056480:4096 @16
2014/09/19 10:30:35 [debug] 27983#0: *110908 HTTP/1.1 500
Server: nginx
Date: Fri, 19 Sep 2014 08:30:35 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
X-Frame-Options: SAMEORIGIN
X-Powered-By: Nette Framework

2014/09/19 10:30:35 [debug] 27983#0: *110908 write new buf t:1 f:0 00007F110C0564F0, pos 00007F110C0564F0, size: 220 file: 0, size: 0
2014/09/19 10:30:35 [debug] 27983#0: *110908 http write filter: l:0 f:0 s:220
2014/09/19 10:30:35 [debug] 27983#0: *110908 http cacheable: 0
2014/09/19 10:30:35 [debug] 27983#0: *110908 http upstream process upstream
2014/09/19 10:30:35 [debug] 27983#0: *110908 pipe read upstream: 1
2014/09/19 10:30:35 [debug] 27983#0: *110908 pipe preread: 3973
2014/09/19 10:30:35 [debug] 27983#0: *110908 input buf #0 00007F110C0554EB
2014/09/19 10:30:35 [debug] 27983#0: *110908 input buf 00007F110C0554EB 3973
2014/09/19 10:30:35 [debug] 27983#0: *110908 malloc: 00007F110C057490:4096
2014/09/19 10:30:35 [debug] 27983#0: *110908 readv: 1:4096
2014/09/19 10:30:35 [debug] 27983#0: *110908 pipe recv chain: 4096
2014/09/19 10:30:35 [debug] 27983#0: *110908 input buf #1 00007F110C057490
2014/09/19 10:30:35 [debug] 27983#0: *110908 input buf 00007F110C057490 4096
2014/09/19 10:30:35 [debug] 27983#0: *110908 malloc: 00007F110C0584A0:4096
2014/09/19 10:30:35 [debug] 27983#0: *110908 readv: 1:4096
2014/09/19 10:30:35 [debug] 27983#0: *110908 readv() not ready (11: Resource temporarily unavailable)
2014/09/19 10:30:35 [debug] 27983#0: *110908 pipe recv chain: -2
2014/09/19 10:30:35 [debug] 27983#0: *110908 pipe buf in   s:1 t:1 f:0 00007F110C055470, pos 00007F110C0554EB, size: 3973 file: 0, size: 0
2014/09/19 10:30:35 [debug] 27983#0: *110908 pipe buf in   s:1 t:1 f:0 00007F110C057490, pos 00007F110C057490, size: 4096 file: 0, size: 0
2014/09/19 10:30:35 [debug] 27983#0: *110908 pipe buf free s:0 t:1 f:0 00007F110C0584A0, pos 00007F110C0584A0, size: 0 file: 0, size: 0
2014/09/19 10:30:35 [debug] 27983#0: *110908 pipe length: -1
2014/09/19 10:30:35 [debug] 27983#0: *110908 pipe write downstream: 1

Popř. ještě tohle:

Nov 21 04:29:31 exiteria kernel: [19255248.877221] php5-fpm[5229]: segfault at 7fffe0429001 ip 0000000000780063 sp 00007fffe0421400 error 6 in php5-fpm[400000+7e2000]

[21-Nov-2014 04:29:31.493920] WARNING: pid 2266, fpm_children_bury(), line 252: [pool www] child 5229 exited on signal 11 (SIGSEGV) after 3.582636 seconds from start

Editoval jasin755 (10. 12. 2014 7:25)

Jan Tvrdík

Proč neaktualizuješ PHP na aktuální verzi, když je to zřejmě chyba PHP?

jasin755

Jan Tvrdík napsal(a):

Proč neaktualizuješ PHP na aktuální verzi, když je to zřejmě chyba PHP?

Dnes v noci proběhne upgrade na 5.6.x tak snad to bude OK.

jasin755

Tak výsledek upgradu na 5.6.3–1 je takový, že jsem musel zrušit memcache session handler a nastavit ho na redis. Jinak to náhodně způsobovalo, že se web načítal např. 15sec a podle XHF profileru 14,5sec trvala funkce session_start();

Počet 5O2 BadGateway po 4 hod. zvrostl s tím, že 502 vrací reverzní proxy Nginx. Samotný webserver je Apache.

Popravdě nevím co mám dělat. Z našeho hostingu, kde máme managed server tvrdí, že si mám opravit PHP scripty (LOL). Jaký je váš názor na toto?

Filip Procházka

@jasin755 to ze mas chyby v aplikaci bych uplne nezavrhoval, ale pokud ti trva otevrit memcache session 14s, tak skoro urcite neco posral hosting a ne ty.

jasin755

Session handler jsem zmenil na redis a je to ok, ale stejne obcas ta 502 tam skoci. Nastesti je zalogovany jeden pripad kdy to nastalo:

2014/12/11 16:25:58 [error] 25173#0: *11664 upstream prematurely closed connection while reading response header from upstream, client: 212.47.2.xx, server: , request: "POST /-1/employees/new HTTP/1.1", upstream: "http://127.0.0.1:80/-1/employees/new", host: "www.xxxx.cz", referrer: "http://www.xxxx.cz/-1/employees/"

Vyvářel jsem zaměstnance v systému. Po tom co jsem kliknul na uložit se mi vrátila 502, ale zaměstnanec se uložil do DB a přišel mu i email o vytvoření účtu. Radši jsem se podíval na posloupnosti a email se odesílá jako poslední, za tím už je jenom return $employees->getId(). A v presenteru nad tím jenom $this->sendJson(..) a pochybuji, že něco z toho by to zhodilo takovou kritickou chybou.

Jen tak bokem. Jak se invaliduje Opcache? Co se stane s běžicími scripty když kompletně resetnu Opcache? Spadnou nebo dojedou do konce?

jasin755

Tak jsem si na to stihnul odpovědět sám. Pokud přes ApacheBench volám requesty a do toho spamuji mazání opcache tak v error logu najdu spoustu řádku:

zend_mm_heap corrupted

a občas nejaký segfault. Zajímavé je, že zend_mm_heap corrupted se přestane objevovat v okamžiku kdy nastavím opcache.fast_shutdown na 0

Azathoth

já jsem taky na hostingu občas dostal 502 a žádná data. pomohlo vypnutí opcache.