Skip to content

Dreamhost VPS Manager Forced Reboot Issues

By Jasper Frumau

I have been using Otto’s Dreamhost VPS Manager for a couple of weeks now to manage my Dreamhost VPS. I do not want to set the memory at 1 GB to cover all peaks and pay a high monthly fee and neither do I want to change the settings manually all the time. The Perl script made by Otto helps you adjusting things on the fly. The only issue I have been having lately is is that every couple of days in the late afternoon or at night I get a reboot done by Dreamhost because demand was too high and apparently my settings did not handle that peak well enough.
I thought about using the built-in option to raise the stakes during certain periods, but I have not been able to pin down peak hours and times. It all seems to be too random. This is my current set up loaded with the command:

~/bin/psmanager.pl check

output:

Check PsManager setup
# PsManager 0.6.3 # 10120 28
2012-09-30 10:52 +07:00
key = SET
microblog =
uname = NONE
pass = NONE
email_rcpt = SET
email_sndr = SET
name_sndr = SET
tweet_template = {ps}: {change} resized to {newsize}MB from {oldsize}MB at {time} [{tz}]
reboot_template = {ps}: rebooted at {time} [{tz}]
mem_min = 350
mem_max = 4000
memory_factor = 1.2
memory_minextra = 0
buffer_perc = 55
buffer_min = 200
force = no
force_lim = 20
monitor_only = 0
pick = 8
ignore = 2
sample_interval = 1
curr_used_factor = 1.1
ps = ps113707
TZ = Asia/Bangkok
verbose = 1
debug = 0

Crontab line(s):
* * * * * $HOME/bin/psmanager.pl >> /tmp/psmanager_cron.log 2>&1

tail /home/me/bin/psmanager.log:
timestamp    avail    used    free    cache    optimal    set    event
201209301046    483    125     357    70     483     0
201209301047    483    113     369    70     483     0
201209301048    483    122     360    72     483     0
201209301049    483    120     362    72     476     0
201209301050    483    95     387    56     471     0
201209301051    483    96     386    56     464     0
201209301105    483    366    116     54     955     955    S
201209301106    955    363    119     54     1023     0     C
201209301107    955    318    636     54     1061     0
201209301108    955    122    832     54     1061     0

tail /tmp/psmanager_cron.log:

Latest events:
timestamp    avail    used    free    cache    optimal    set    event
201209291304    614    38     575     66     393     393     S
201209291305    393    46     567     68     393     0     C
201209291709    393    39     353     69     343     350     S
201209291710    350    121    228   101   349     0     C
201209291729    350    32     317     75     424     424     S
201209291730    424    47     302     75     424     0     C
201209291902    424    34     389     76     366     366     S
201209291903    366    43     380     76     367     0     C
201209292004    366    107    258   110   427   427     S
201209292005    427    117    248   110   426   0     C
201209292236    427    123    303   104   570   570     S
201209292237    570    118    451   120   575   0     C
201209300038    570    76     493     121   391   391     S
201209300039    391    76     494     121   390   0     C
201209300131    391    42     348     105   478   478     S
201209300132    478    42     348     105   478   0     C
201209300159    478    31     446     9     418   0     B
201209300335    478    44     433     21     402   402     S
201209300336    402    78     399     37     401     0     C
201209300915    402    90     311     16     393     0     B
201209300926    402    132    269     43   465   465     S
201209300927    465    129    272     44   464   0     C
201209300939    465    331    133     63   887   887     S
201209300940    887    328    136     63   937   0     C
201209301041    887    91     795     55     483     483     S
201209301042    483    115    367     53   483   0     C
201209301105    483    366    116     54   955     955     S
201209301106    955    363    119     54   1023   0     C

Errors and Warnings in verbose log:

Check complete

Seems all pretty standard to me. Earlier this morning when I edited a blog post and checked some stats I got myself another reboot. See the two reboots in the log as proof. One happened while I was asleep and the second one happened when I wanted to do some work. Apparently the VPS had had very little traffic and then got a huge surge et voila down it went! How can I deal with this properly without being forced to go for a minimum of let’s say 500MB?

One of the reboots happened earlier today:

201209300131    391    42     348      105      478       478      S
201209300132    478    42     348      105      478       0        C
201209300159    478    31     446      9        418       0        B
201209300335    478    44     433      21       402       402      S

Update I

I have added XCache after I switched back to PHP 5.2 CGI and I have added WP Cache to this site. I also turned of Stats added by Dreamhost on all sites. Let’s see if this will finally help me not getting an occasional reboot because of a memory shortage

Update II

I found out that I needed at least 600 MB of RAM to run 5-6 WordPress sites and a static one. This to deal with peaks and make sure reboots do not occur. If I would switch to NGINX I would probably need way less memory. But setting up an NGINX server with WordPress without the use of .htaccess is something I do not want to get into just yet. Might open up another VPS again and try it all with this site a little later on. But for now I am willing to pay more than the amount in $ I was paying for the 350MB. Going for 600MB has made sure I have not had any nasty reboots in a long time. Running

ps aux

or

top -c

Showed that I had large peaks on the logging into the Dashboard. I also suspect that the WP DB Backup database plugin and CodeGuard’s backup services eat up a lot of memory. But I would need to do more research for that. I also found out that WP Slimstat and WPML (Site display in two or more languages) are plugins that demand a large chunk of all the queries.