pegasus
Well-known member
From nginx logs, many many times:
PHP-FPM logs showed nothing out of the ordinary. After all, it was just closing and opening child processes as it was expected to do as needed or when they became stale.
These errors always occurred at the same time the browser proclaimed Error 337 (net::ERR_SPDY_PROTOCOL_ERROR). I was able to reproduce this issue many times per hour personally (honestly I don't know if anyone else ever encountered the issue), but it resulted in partially rendered pages, often with absolutely no text content (just styled backgrounds and empty divs). It was only after disabling fast-shutdown that both the readv() and Error 337s stopped instantly.
nginx 1.7.4 w/ SPDY + PHP-FPM 5.5.15 (at the time) w/ Zend Opcache 7.0.4 dev
I only thought to look at the Zend Opcache configuration because it seemed I only started noticing the issue within a few days after enabling Zend Opcache (around that time I had also enabled SPDY).
Code:
[error] XXXXXX: *XXXXXX readv() failed (104: Connection reset by peer) while reading upstream
These errors always occurred at the same time the browser proclaimed Error 337 (net::ERR_SPDY_PROTOCOL_ERROR). I was able to reproduce this issue many times per hour personally (honestly I don't know if anyone else ever encountered the issue), but it resulted in partially rendered pages, often with absolutely no text content (just styled backgrounds and empty divs). It was only after disabling fast-shutdown that both the readv() and Error 337s stopped instantly.
nginx 1.7.4 w/ SPDY + PHP-FPM 5.5.15 (at the time) w/ Zend Opcache 7.0.4 dev
I only thought to look at the Zend Opcache configuration because it seemed I only started noticing the issue within a few days after enabling Zend Opcache (around that time I had also enabled SPDY).
Last edited: