Intermittent 524 errors


#1

Over the last few months my site has experienced multiple 524 (timeout) errors. When this happens the site is unreachable for several minutes, and since I cannot monitor the site at all times it is unknown how frequently this actually occurs. Downtime robots are of little value since they don’t seem to catch these errors.

The site is on a shared server, so it could be any site sharing that same server; In other words I don’t have a prayer of figuring out the source of the problem nor resolving this issue without dreamhost’s assistance. How many active sites does dreamhost cram onto one server? Is the server load considered when adding more sites? Type of hardware? What can be done about this?

error 524 explained


#2

Cloudflare is skilled at passing the blame. It very well could be the users’s connectivity with Cloudflare.

However, as always, start with the source and work outward… compare the timestamp of the reported errors with those in your error log. The error log will usually give you a pretty accurate reason for the problem.


#3

ok, good point. There are a few errors, and they always start with this line:

[core:error] AH00574: ap_content_length_filter: apr_bucket_read() failed

Could you shed some light on what that means?


#4

Appears something may be hitting a memory limit, most likely a script you’re running.

Try doing a web search for the error itself:

“AH00574: ap_content_length_filter: apr_bucket_read() failed”


#5

Yes, I did that and found (probably) the same sites you did, but that does not help to troubleshoot the problem. I have been trying all day and have not been able to repeat this issue, it seems arbitrary.

Yesterday around noon EST and today around 9:00 EST it happened a few times, but otherwise there are NO ERRORS in the log. It is not repeatable, and there are no intermittent scripts that run on my site. Usually the site is very zippy (scores 100 using chrome’s audit). For comparison the log files on my local server show zero errors (I always verify before uploading to dreamhost).

The scripts on the site are relatively simple, mostly they send/receive SQL statements and parse out the SQL data. If the problem is on my side it is most likely with mysql. I spent the last hour monitoring the mysql process via “top” in linux and the memory use is consistently low, between 20 and 200 MB (linux is vague due to shared processes).

My only conclusion is that this is a server problem, but without dreamhost’s help I have little chance of resolving it.


#6

Another site(s?) on your server may be hogging memory resources, then when your processes run you hit the limit.

This is always a downside of shared hosting. Usually this is balanced well, but occasionally there’s collateral damage.

If it persists, you could ask Support to investigate, but unless the abuse is blatant and identifiable, the likely result will be suggestions to either move your site to another shared server or to upgrade to either a VPS or Dedicated server.

I would also continue research for ways to improve mysql processes.


#7

The mysql code is already very light on resources (imo) but I frequently tweak it to speed it up.

Shared hosting is like I am working with a black box, frustrating.

In the meantime I spent the last day trying to solve this problem, pushing aside all asumptions. I stumbled into this:

https://stackoverflow.com/questions/33173743/connection-reset-by-peer-ap-content-length-filter-apr-bucket-read-failed

To keep a long story short, now I temporarily save the POST data to the SESSION, then unset the POST data; so if a bad actor sends ignored POST requests to the site it won’t crash the site.

I don’t know if this will solve the problem, but it does have one major side benefit: No more annoying “confirmation” boxes when a user refreshes a page that contains POST requests. For more on how, see this link:

https://stackoverflow.com/questions/8335828/how-to-delete-post-variable-upon-pressing-refresh-button-on-browser-with-php