DreamHost 404 when working in admin

  • Resolved kgagne

    (@kgagne)


    13 years, 10 months ago

    I have a VPS with DreamHost. In the last few months, I’ve been getting more and more 404s while using WordPress 3.0.4’s administrative interface, such as publishing posts, activating plugins, or approving comments. The only recurring error I see in my error.log file is “Premature end of script headers“. Even the frontend of the site can take 15+ seconds to load, if at all, as indicated by Pingdom Tools. Though I’ve set my VPS’s memory limit to 374 MB, my admin panel rarely shows usage above 247.

    I’ve read several threads on similar issues and have followed some suggestions, such as pruning my plugins and adding this line to my wp-config.php file:

    define('WP_MEMORY_LIMIT', '90M');

    and disabling this line that’s added by DreamHost’s one-click installer:

    $base = DB_NAME;

    I’ve not installed any caching plugins, as even though I currently run 16 WordPress sites, none of them receives more than double digits of pageviews per day. (Only half accept comments; most have revisions disabled.) I had DreamHost’s Google Pagespeed option enabled for awhile, but it seemed to make things a bit worse, so I disabled it.

    With all my plugins enabled, my site makes about 22 queries to load the homepage. The TPC plugin pointed out one instance of high memory usage that involved 38 database queries — presumably while I was accessing the admin panel.

    Here are some other statistics reported by the TPC plugin when loading a page:

    TPC! Memory Usage (https://webjawns.com)
Memory Usage: 23413816
Memory Peak Usage: 23749872
WP Memory Limit: 90M
PHP Memory Limit: 90M
Checkpoints: 7

    From the admin dashboard:

    Usage Sample: 30.62MB (12%)
Peak Usage: 30.87MB (12%)
All-Time: 22.33MB on 2/1/11 @ 11:28 pm (wp_head)
Load Averages: 0.23 0.28 0.28
WP Memory Limit: 90M
PHP Memory Limit: 90M

    I’ve recently optimized my databases via phpMyAdmin. I also ran a free Load Impact test.

    Despite these efforts and diagnoses, my problems persist. Do any of these numbers look unusual? Any suggestions of what I could try that I haven’t already?

Viewing 11 replies - 16 through 26 (of 26 total)

  • Yeah, but I’m not even sure my stuff has all been moved over to the VPS– I show almost no usage, even though it’s been 12 hours and it all should have moved by now.

    I guess I’ll go poke DH and see if they can tell me that much, at least.

    Dealing with a similar DreamHost issue with a plugin heavy site and I am writing about it here: https://www.ads-software.com/support/topic/backend-errors-premature-end-of-script-headers?replies=8#post-2007448 . I might have to ask the client to upgrade to a VPS as well… Never had this procwatch memory kill easy with other webhosters before.

    Having the same issue with tasks I typically do that does not happen on my other host.

    I have a number of sites that are based on different topics but have the same structure and plugins. I started on Bluehost and recently decided to launch my newest on on DreamHost to compair.

    Tasks I usually run such as add a new catecory or tag and then apply it to existing posts usually results in this listed 500 error, this NEVER happens with the same site setup different content on bluehost.

    I’m still in trial, but will not stay if this cannot be resolved.

    New site I am building on dreamhost
    https://onlinecomputersupportandrepair.com/

    Existing site on bluehost
    https://freeappliancerepairmanonline.com/

    Sorry to bump this thread. While this is a DreamHost-specific issue, DreamHost are listed as close partners of Automattic, so I guess many WP sites run on them.

    Like many WP users, I’ve done a lot of tests, and the 404/500 errors pop up no matter what. But finally I’ve traced it down, thanks to this useful article: https://boomshadow.net/tech/php-handlers/

    Since I have all my sites on PHP FastCGI (to improve performance and be less ‘demanding’ on DH’s servers), I didn’t realise that it consumes far more RAM than “normal” CGI. Also, PHP 5.3 is far better at managing RAM than PHP 5.2. Nice and cool modules like Web Security and Google’s Page Speed also consume RAM in exchange for better performance and more security. With all that, WP processes tend to go over DH’s RAM limit.

    Well, so right now I’m using PHP 5.3 with “normal” CGI, turned off Web Security and Page Speed, and use W3 Total Cache and Cloudflare as an external caching/reverse proxy system instead. W3 Total Cache will neatly “accelerate” the pages by compressing them, using Minify on CSS + JS, and so forth — and also make sure they all get statically stored, both on disk and on the user’s browser. To deal with bandwidth and speed, Cloudflare does the trick, by caching about 40-60% of all requests — and additionally running a security check on the pages as well (which might be better than DH’s own system). Since Cloudflare is externally hosted, well, they can consume as much RAM they want, it won’t interfere with DreamHost and still give excellent performance. ??

    @ Gwyneth Llewelyn Thanks a lot for all the information! Looking into Cloudflare and into FastCGI versus CGI and performance. W3 Total Cache is a plugin I have been using a lot already and it has helped out a lot. But now that I have more tips I can perhaps avoid more of these cutoffs. Thanks again!

    Thread Starter kgagne

    (@kgagne)

    Gwyneth,

    Bump away! As far as I’m concerned, this topic is still relevant. Lately, I’ve gone from 404s to flat-out “could not connect to server” messages. I have to reboot my VPS and increase the RAM, which in the last two weeks has gone from 750 MB to 1250 MB — a significant price increase for someone like me. Here’s DH’s response to my experience:

    I’ve looked into the cause, and have found that your VPS has been spiking above it’s set memory usage. When a VPS spikes above it’s set memory limits a couple of things happen on the physical machine on which it runs. First an application called “OOM Killer” is invoked. This application forcibly ends the process running on the VPS in order to return the guest’s usage to a state which is within it’s set limit. Now, previously after this happened the VPS would then be able to spawn that same thread, going right back over the memory limit, and it would be killed by OOM killer again. The main issue with this behavior, was that due to the number of spikes, OOM Killer itself would drive up the load on the physical machine, slowing it down, and causing issues on all customer’s VPS. We’ve prevented this behavior by installing a helper application which runs after OOM Killer has terminated an errant process. This helper application, “Hurt Locker”, temporarily freezes an offending VPS, which prevents it from spiking over the memory limits on a constant basis, and keeps the machine itself running well and other customers from being affected by an under-allocated VPS.

    As your VPS is in fact spiking over it’s set memory limits, you will experience 500 errors, connection errors, and general site unavailability.

    Your VPS has been frozen by Hurt Locker 67 times according to the following log. This strongly indicates that your memory levels are not sufficient for the sites and/or traffic on your VPS

    Please understand that while you may not be hitting your disk space or bandwidth limits, these are actually entirely different things. Also, as the spikes typically occur and are then subsequently killed within milliseconds, they often don’t register on the panel memory usage graphs at all(We will however be making the hurt locker logs available in the panel ASAP).

    I thought I’d switched all my sites to PHP 5.3 and disabled Google Pagespeed, but I see a few are still on 5.2. I had no idea that FastCGI, being “less demanding on DH’s servers”, could use more RAM, or that the web security module also consumed resources.

    I’ll have to look into Cloudflare. I don’t use a caching plugin as my 17 WordPress sites average only about 100 hits per day each, which doesn’t seem like enough to warrant caching.

    How long have you been using the configuration you described?

    Thanks for the tips!

    -Ken

    Thread Starter kgagne

    (@kgagne)

    Gwyneth,

    I moved all my sites from PHP 5.2 FastCGI to PHP 5.3 CGI. My memory usage immediately dropped from almost 1000 MB to 100 MB. What a difference!

    I did not disable extra web security, and I enabled CloudFlare on only one of my sites as a test. Neither seems nearly as significant as the PHP change.

    Thanks!

    -Ken

    Gwyneth, thank you so much!

    I really like DreamHost, and I didn’t want to change, but that damn error was driving me crazy! I switched to PHP 5.3 CGI and haven’t had a problem since.

    For the record, I left Web Security on and I don’t use W3 Total Cache or Cloudflare.

    Just switched to PHP 5.3 Normal CGI. Seems to be an improvement to the site’s loading speed. But still had an error:

    Fatal error: Allowed memory size of 94371840 bytes exhausted (tried to allocate 71 bytes) in /home/user/domain.com/wp-includes/cron.php on line 221

    using Scribe SEO. Memory limit is 128MB

    define('WP_MEMORY_LIMIT', '128M');

    Hmm..

    Thread Starter kgagne

    (@kgagne)

    May want to ask the ScribeSEO guys for help on that.

    https://my.scribeseo.com/

    The immediate results of switching from PHP 5.2 fastcgi to PHP 5.3 cgi in the dreamhost VPS memory usage graphs are stunning.

    Glad I found this thread. Got more benefit in just a few minutes than many back and forth messages with dreamhost support.

Viewing 11 replies - 16 through 26 (of 26 total)
  • The topic ‘DreamHost 404 when working in admin’ is closed to new replies.