Page loading crashes

Question

PHP

Good afternoon.
The issue has become an edge, it is necessary to urgently resolve, all the measures taken based on the results of the search in the search engines were taken, they did not help.

There is a server (Ubuntu 13.04, 3.8.0-29-generic) running Apache /2.2.22 and PHP 5.4.9-4ubuntu2.3 .

When moving through the pages, every 10th (sometimes more often) “breaks down”.
By "fails" I mean that only part of the page is loading. In this case, the browser further shows the page loading bar. But nothing happens.

If you reload the page, then everything is fine.

Those. this manifests itself with some frequency on completely different pages, completely different sites (apache virtual hosts).

Previously, there was no such problem. It is difficult to say what caused the appearance (if I had known, I would not have asked the question) .

The problem is clearly not in the PHP files, but in the configuration of Apache itself.

Thank you.

UPD 1:
Restarted Apache and mysql twice as a matter of urgency and so far everything is running smoothly.
I think the problem is related to some kind of buffer, or storage, which is cleared when Apache is restarted.

Then such a question, perhaps scheduled restarts of Apache are necessary ? Let's say at 4:00?

UPD 2:
There are no errors or warnings in the logs.

UPD 3:
In principle, there are enough resources.
For a long time I tried to make this error come up again. ab helped, made 300 requests in parallel, and the server crashed...

Results for the main page:

**.**.**.** - - [30/Oct/2013:14:19:22 +0200] "GET / HTTP/1.0" 200 54088 "-" "ApacheBench/2.3"
.... 52 раза одно и тоже.....
**.**.**.** - - [30/Oct/2013:14:19:22 +0200] "GET / HTTP/1.0" 200 54088 "-" "ApacheBench/2.3"
**.**.**.** - - [30/Oct/2013:14:19:22 +0200] "GET / HTTP/1.0" 200 54088 "-" "ApacheBench/2.3"
**.**.**.** - - [30/Oct/2013:14:19:22 +0200] "GET / HTTP/1.0" 200 8688 "-" "ApacheBench/2.3"
**.**.**.** - - [30/Oct/2013:14:19:23 +0200] "GET / HTTP/1.0" 200 8688 "-" "ApacheBench/2.3"
**.**.**.** - - [30/Oct/2013:14:19:23 +0200] "GET / HTTP/1.0" 200 8688 "-" "ApacheBench/2.3"
.... 174 раза одно и тоже.....
**.**.**.** - - [30/Oct/2013:14:19:23 +0200] "GET / HTTP/1.0" 200 8688 "-" "ApacheBench/2.3"
**.**.**.** - - [30/Oct/2013:14:19:23 +0200] "GET / HTTP/1.0" 200 8688 "-" "ApacheBench/2.3"

As you can see, the size has decreased from 54088 to 8688 bytes.

UPD 4:
I tested 3 times. Apache stops responding correctly (drops all subsequent requests) at ~34 simultaneous requests (100% CPU load). And comes to life in 2-5 seconds.

But that's a little different. Because in the worst case, the server (with its attendance) on average simultaneously 1 - maximum 3 requests.

So far I see one way out - to restart Apache at least once a day ...

Answer 1

Can you open a fire bug at the moment of failure and see what files the browser is waiting for indefinitely? New every time?
Are there any errors in php? It looks like something with the Internet, like yota, when packets are lost often.

Answer 2

Large static files are returned normally?
Are there enough resources? Apache reboot fix looks like memory leaks.
Is the full or partial size shown in access.log for partial loading?

Answer 3

Run jmeter or at least ab so that you don't suffer with your hands.
Run a ping of the server.
Then look at the logs - systems, Apache.

Answer 4

run not just ping the server. A ping with a packet size equal to the mtu of your server.
Often there are problems with the MTU on some of the hops.
And just a ping of 32 bytes goes well, but large pings disappear.

Answer 5

I had a similar situation on a non-development machine. the customer actively used the output buffer, and in some cases Apache did not automatically flush the buffer.
on the development machine, I solved this with ob_flush() at the end of each script and everything worked out, and since there was no such error on the production, I did not investigate the problem further.

Answer 6

clamp-mss-to-pmtu? Very similar symptoms. Well, or just reduce the MTU on the (client) interface.

Answer 7

Are errors written to the log? error_reporting what? and in that log? otherwise puff can write both to its own log and to the Apache log,
make some kind of file, for example, division by zero, and check if it is displayed in the log

Answer 8

By the way, sometimes it helps to kill unused Apache modules (especially those related to proxies) I had problems on the production server because of them, but the symptoms were not the same (I suspect someone tried to connect through them and there were a lot of left processes in the network statistics , I immediately say I’m not strong in administration and therefore I just killed everything related to the proxy in Apache - it helped me).