Is Dreamhost PS simply a way for Dreamhost to wash their hands of support?

Another month, another total crapdown of my sites which are hosted at the moment in Dreamhost’s Virtual Private Server offering. Once again the story begins in the usual way, all three of my  sites start puking Internal Server Errors all over the place which generally means that you are out of available RAM on your server. As I generally have about 180 Mb of availability, it would meant that either I have a huge amount of traffic that my Cache did not alleviate, or that something is going wrong on the server.

Going to the Resource Management, I am greeted by a classic figure

Up, up and away!
Up, up and away!

Having looked at my traffic already which had stayed steady in the last days, I know that this is certainly caused by some server/app malfunction. I know this from experience because the same goddamn problem happens to me so regularly, it’s not even funny anymore.

Since this happened while I was at work, I could troubleshoot it through the terminal as they have the ssh ports blocked so I had to wait until I came back home to investigate. Once I arrived, I fired up an ssh connection and checked what processes were running. As expected, it was PHP in CGI mode that was sucking my life’s blood.

Bad PHP. Baaaad!
Bad PHP. Baaaad!

Now mind you, I know all this because I’ve done it before where I had to google around and learn which commands to use to discover this info. The first time it happened, my ram usage was slowly creeping upwards in jumps of 30 Mb per week or so. After that, it simply happens all at once suddenly.

Now this is extremelly difficult to troubleshoot as you can have no idea what is causing this. A php5.cgi process can be anything under the sun that runs on PHP. Basically the whole wordpress interface or any of the dozens of plugins I have installed. You can kill the processes but this will not tell you what is happening and as it does not happen persistently, you can’t figure out which plugin might be causing it as shutting down a plugin does not stop the process and you don’t know when a process will get stuck again.

Unfortunately, and this is what is annoying me mostly, Dreamhost’s answer in the past has been that “It’s not our fault. Figure it out yourself”. A very unfulfilling answer as you might guess. But at least I know that I can expect very little help from them anymore so I avoid them.

So then I got to process killing. Unfortunately this time it seems that I had found a resistant strain of bug. As soon as I killed a process, 5 seconds later and a new one would be spawned, then another and another, until all my RAM was eaten up, no matter how much I increased my available. At this point I was fast reaching a deadend with my current skills as I couldn’t make the problem go away. I couldn’t even access my wordpress’ admin panel to disable plugins.

At this point, a former colleague suggested that this might be caused by a known PHP 5.2 bug which leaves processes hanging when done with them. I thought this might be a good thing to suggest to Dreamhost support to check so I fired up a support ticket.

A while later, I noticed that the RAM usage seemed to have dropped off so I thought that the problem had resolved itself. Unfortunately, while the main page was working the admin panel refused to work.

What admin panel. There's no such thing here
What admin panel. There's no such thing here

In desperation I did a quick server reboot and this was the point where the universe b0rked. After the reboot the whole site was off and my memory usage was stuck at around 20Mb which means that basically the whole thing failed to load. I fired a new ticket to support and waited.

I had to wait until today for an answer which basically told me that they managed to get the sites running again but advised me that my RAM usage was high so I should be checking that and no, they still can’t help me. Thanks Sherlock…

Looking around the interwebs however, I did stumble on a page in the dreamhost wiki where there was a note under supercache under caching that warned not to utilize the “super” part of WP Super Cache as it may drive resource use up on Private Servers. Gee, it would be nice if I knew of this a bit before. It would also be nice if Super Cache was not installed as part of the standard one-click installation of WordPress by Dreamhost which makes people assume that if anything, this plugin will be working well.

So I disabled Supercache on the Division by Zer0 and on the Wesnoth Journals and killed the remaining php processes. Lo and behold, no more processes were spawned. Unfortunately I was lucky that I could access the admin panel of these two sites after I increased my available resources to some ungawdly amount (1.5Gb of RAM or so). Unfortunately I was not so lucky in the Antichristian Phenomenon where not only I could not access the admin panel (never finished loading) anymore but the php processes kept spawning repeatedly and fast.

I tried deleting the plugin directory which led to my whole page being turned off. I tried fixing the .htaccess file. Nothing. Anything I tried, I couldn’t get the site to work properly. So I did the only thing I could do, renamed the whole wordpress directory and reinstalled again. At least this gave me an opportunity to finally rename the prefix of my database tables which helps avoid zero-day exploits by script kiddies. After a few hours, the site was back online.

Unfortunately the latest ordeal has really disillusioned me about Dreamhost’s PS and their support of those. From the 3 times I’ve contacted them about issues in randomly increasing resources, their reply has been “Deal with it yourself” because apparently now I control everything on the server and if anything goes wrong, it must be my own scripts or whatever. Seeing as I only use standard software like WordPress and Gallery this reply does not help me much.

Basically what seems to be happening is that when one decides to go to a PS in order to get a bit more speed (since shared hosting seems at time to be powered by hamsters) you’re on your own. If you’re not a (quite) techical user and have made the grave error of installing wordpress plugins on your site, you’re fucked. It seems that as far as Dreamhost is concerned, you shouldn’t be running plugins in the first place. Just vanilla WordPress for you.

Luckily for me, I know a few UNIX commands and how to use an ssh shell to do some troubleshooting. However even for me this kind of response is definitelly inferior. It would be nice if I could expect the Dreamhost support to ask questions like “Are you using WP Super Cache?”, or something similar. It would be nice to expect the support people to know of a few issues that generally might cause this kind of trouble. Is this is all too much to ask? Is it too much to ask to expect some attempt to help your users?

Last time I was delighted when the support tech gave me a simple command to help me trouble shoot but since then, all replies have been to explain me that it’s my own damn fault and this is very disheartening. To everyone considering the Private Server offering, if you’re not very technical and open to spending a few hours now and then to troubleshoot random issues that occur without you changing anything, then stay away from it and stick to simple shared hosting.

As for me, now my sites are all in the classic WP Cache mode and I’ve used Hyper Cache for the ACP to see how it goes. If all goes fine, I will switch everything to Hyper Cache and drop Super Cache altogether. ‘Till next time my site craps down…

Reblog this post [with Zemanta]

36 thoughts on “Is Dreamhost PS simply a way for Dreamhost to wash their hands of support?

  1. I don't think it's your site's traffic causing this.
    Unfortunately I don't have access to your server's logs (not only Apache ones), so you have to look at them.
    I suspect a DoS attack at your SSH, but can be anything.

    1. It's definitely not traffic causing this. I don't think it can be a DoS attack at my SSH as it does seem like a PHP bug in combination with a wordpress plugin and the specific configuration of apache/php on Dreamhost's side.

      1. Except if you run a very rare plugin, I don't think it's the case or else many WP blog sites would same problems as you.
        Well, logs are there for a reason… Check them out!
        I hope to prove me wrong but in case you haven't changed something, it's a server attack.

          1. Meh…
            I've heard horror stories about WP-Supercache in the past but didn't expect that much damage.

            And here is a question for you:
            You run both PHP 5.2.6 *and* PHP 4.4.7 through Apache?
            Your headers as returned for every page of your site:
            Server=Apache/2.0.63 (Unix) PHP/4.4.7 mod_ssl/2.0.63 OpenSSL/0.9.7e mod_fastcgi/2.4.2 DAV/2 SVN/1.4.2
            X-Powered-By=PHP/5.2.6

            Who configured that?
            Maybe I am missing something here?

          2. Hmm, this could be simply the general Apache config that Dreamhost has, as you can activate either PHP5.2 OR 4.4 through mod_php (I guess to ensure compatibility with those who still use it) per domain. As I am still using the shared instance of Apache, I can't change that but it looks like PHP5.2 is used as it should.

            We'll see how it progresses. If I get the same problem, I'll try switching completely to Hyper Cache everywhere and see.

  2. See, this is why I don't go with a private server for my stuff. I don't want to have to know all this sort of stuff, and the people who are supposed to support you can never actually do so because there are practically infinite ways for you to have changed things so that their experience is useless.

    In fact, the exact same thing could be said of Linux for the desktop.

    1. In fact, the exact same thing could be said of Linux for the desktop.

      Or MS Windows…

      In any case, the idea is not to tell you exactly what is wrong but at least give you some pointers on where to look. Speaking from my professional experience as a support technician I can easily tell just by hearing about a problem what might be the issue and how to start troubleshooting.

  3. Meh…
    I've heard horror stories about WP-Supercache in the past but didn't expect that much damage.

    And here a question for you:
    You run both PHP 5.2.6 *and* PHP 4.4.7 through Apache?
    Your headers as returned for every page of your site:
    Server=Apache/2.0.63 (Unix) PHP/4.4.7 mod_ssl/2.0.63 OpenSSL/0.9.7e mod_fastcgi/2.4.2 DAV/2 SVN/1.4.2
    X-Powered-By=PHP/5.2.6

    Who configured that?
    Maybe I am missing something here?

    1. Probably a problem with the chosen host…
      My guess is that this happened because he didn't like to see his bank account balance to have a division by zero error! ^_^

      1. heh. The problem was a combination between a wordpress plugin and my host. For some reason supercache b0rks VPS hosting and DH is aware of it. They mention it in their Wiki as well but the support tech on my call was not aware of it obviously as he didn't ask me to check that.

  4. Thanks for this, it might be useful for me. I've also had a lot of problems with the Dreamhost PS, the memory seems to be climbing every day and I can't seem to stop it. I will try disabling all the 'Super' parts of WP-Super-Cache that I have running on my sites and see if that helps. If not, I'll try Hyper Cache.

    The funny thing is, I had WP-Super-Cache fully enabled on loads of sites when I was first moved to the PS, and even after I cut the memory to 150mb after the first week, they were all still working fine. Then slowly, 500 Internal Server Errors started to creep in – so I raised the memory allocation- then I got more errors and more memory usage, and it seems the more I raise it, the more it needs!

    I've written to Support about it, but whaddyaknow, it won't submit my Support ticket, it just hangs on 'Submitting your ticket.' F'in typical…. I am rapidly becoming a 'DreamHost Sceptic'…

  5. WordPress is crappy. They don't provide support for what you run, just the hosting itself.

  6. WordPress is not crappy- if it were why do they provide it as a one-click install?

    And how can they provide support for just bare hosting? If you just paid for the hosting and were running nothing on it, then of course you'd have no problems.

    When support got back to me, they told me that I should run all my sites under mod_php and not to run them under php as a cgi- when I did this the memory usage dropped considerably. There were a couple of plugins causing problems too and I disabled them as well. I got the mem usage down from about 400mb to about 120mb!

    I must say that the attitude of the DH support was rather arrogant and expected me to know everything about running a VPS already- like it was obvious php as a cgi would cause memory outages. He told me that under the shared hosting they are running as mod_php so I asked why the sites were not kept as mod_php when they were switched over to shared hosting. Answer came there none… but of course the more memory they use, the more money DH makes.

    1. Hmm, no-one ever told me about mod_php really. Is there anything one needs to activate it? How do I see which one I'm running (taking a look now at my domains doesn't seem to list it)

      But yeah, mileage with DH support may vary. From the lazy to the arrogant to the really helpful. I've had one guy tell me that unless I'm prepared to do exactly as he tells me (disable most of my plugins) he wouldn't be able to help me

  7. I had this problem last night. I was able to ssh in for a little while and when I checked top, I saw there were a *lot* of sshd processes being initiated by root. I saw one sshd owned by my user, so I think that would imply that users ssh'ing in own their own process, but I haven't even gotten a system generated acknowlegement of my plea to support yet (and it's been 12+ hours), but I digress…

    I went ahead and changed wp-supercache to "half-on" mode, where super cache is disabled and only regular cache is being used… is that enough, or should I completely uninstall and eradicate any trace of wp-supercache?

    Also, I wonder how much validity there is to the possible DoS attack on ssh…. I was able to get into ssh for a short time and when I checked top, there were a *lot* of sshd processes owned by root. There was an sshd process owned by my user, so I would think that implies that there was something going on that wasn't me.

    To add further fuel to the fire, many years ago, I had a linux box that was compromised and the hackers put in a program that would initiate outbound ssh connections to a server in China and then use the machine as a proxy. I had root on both the server and the routers and firewall then, though so I could see what was going on and plug the holes. In this situation, I can check a few things and then cry to DH, pray for an answer (and like last night, just give up and go weep into my pillow).

    So I dunno… sounds like we're in the same boat though, so if you find anything new, let me know.

    1. Hey Carolyn, I feel your pain. I've since resolved my issues but I went through a bit of teeth grinding to figure it out. I would advise you to remove Super-Cache and switch to Hypercache if possible. It's worked wonders for me. Check this article.

      I don't think there's much possibility of a DoS attack but there's alwaysa possibility of being hacked. if you discover something like this at least DH is quicker to respond.

      1. I got a reply from Brandon (it wasn't tremendously useful, but I've corresponded with him before and he's usually pretty helpful). I replied back and explained what I'd found out just googling for things and mentioned that a little heads up in the start up info they send to new PS users would have saved a lot of grief. I also mentioned the weird sshd processes *shrug* We'll have to see if that gets a response.

        I'll go take a look at hypercache now…thanks again!

  8. At least I'm not alone. The DreamHost PS is extremely disappointing. If only it could tell me which URL(s) were using the most resources…

  9. Checkout memcron.
    The author will (hopefully soon) be adding a feature that will "Reboot Server if CPU load exceeds limit for certain period of time", maybe you can set this to also Reboot if Memory is exceeded?
    HTH,
    -BassKozz

    1. I took a look at it already before but I don't think it can help me with my particular issue. It seems that there's something corrupting a database table and making the whole thing grind to a stop. I haven't figured what yet…

  10. Thanks for posting this. I run two relatively low frequented blogs with the "normal" Dreamhost hosting. Now Dreamhost offered me 66% off the minimum price of Dreamhost PS (first they offerered 33% off and now literally begged me to take the new offer) and I was really considering moving at this price. However, as your post shows, it might cause more problems than I want.

  11. sorry to hear about your troubles. good to know about wp-cache (that it can crash your box).
    I wonder if wp-cache has been improved since you have written this and anyone has tested the 'super' mode

  12. Hey, So are you still using DreamHost or have you changed your hosting provider? More and more customers are becoming disappointed due to strict restriction on WordPress plugins from DreamHost. Hope DreamHost will solve this problem.

    1. No, I've moved away from DH just last month. I had no restrictions on wordpress plugins because I was on a VPS, but the performance of the whole thing had become attrocious in the end for the money I was paying.

        1. Until now it's been great. About 3 times as fast in loading in general and can run all my plugins again. There was one server timeout at one point for 1 minute or so but that's about it.

Comments are closed.