One particular problem I and several other people run in to every now and down on their VPS, is that trying to downsize a VPS sometimes leads to a forced reboot. We then usually get an e-mail like this one (some get this several times per day, I only get it every few days/weeks):
[quote]You asked us to resized your VPS (ps9296) to 300MB, but it was using
311MB when we tried. Because you asked us to force the change anyway
we went ahead and rebooted ps9296 for you. You can see this change in
the panel here:
To prevent this from happening in the future, make sure your server is
using less memory than you try to limit it to!
Enjoy your newly compacted VPS!
~The Happy DreamHost VPS-Resizing Bot![/quote]
Now of course, there is a flag with the resize API call (and tickbox on the panel) telling Dreamhost to “force” the downsize. This means we can technically avoid the reboot by not setting that flag. That however doesn’t deal with the issue we have with this.
Not forcing the downsize causes either the downsize to fail if you try to set the correct amount of memory for your needs, or forces you to reserve more memory than you really need.
Maybe it’s best explained with an example so let’s look at the memory usage of my VPS the minute before my automated script (PsManager) decided to downsize it from 400 MB to 300 MB (which led to the reboot mentioned in the e-mail I quoted above):
Total memory available: 400 MB
Total memory used: 47 MB
Total memory free: 352 MB
Total memory used for cache: 269 MB
Now clearly it was only using 47 MB and not 311 MB as claimed in the e-mail. My logs also showed that my VPS had 352 MB of free memory at that time. A downsize to 300 MB (the minimum) was perfectly reasonable.
The problem with the DH resize robot arises from the fact that it considers the cache as memory that you are supposedly “using”. Indeed when we add the 269 MB cache to 47 MB we get 316 MB, which is close to what the e-mail stated (and above the 300 MB we requested).
The cache however isn’t memory that you are using for your processes, so you don’t really need it to keep your VPS running. The operating system simply uses free memory to cache the disk, which makes disk access faster. This is a nice feature, after all it’s better to use the memory for something useful then to let it be idle.
However that is still no reason to force a reboot of the VPS as the cache could simply be cleared by the DH resize robot prior to downsizing. The instruction for that is one simple line of code that needs to be performed as root (admin user):
After clearing the cache, the resize could be performed without a reboot.
A second option, would be for DH to provide an API call to clear the cache, and I have filed such a suggestion (via the DH panel), here: API call to clear the cache. I’ve asked people who wanted to avoid the reboot to vote for it (and please do still vote for it if you haven’t yet). However the suggestion was submitted back in March, 9 months ago. Nothing has happened since.
The two solutions above are the cleanest options, I really wish Dreamhost would implement one or the other.
On our side there are other possibilities. The first is to run PsManager as an admin user and have it issue the cache clearing command. However I do not like the idea of running anything as an admin user, especially as for most people, my software is 3rd party software. That requires a certain amount of trust and it’s just strange to give a script access to everything on a VPS just for 1 bit of functionality. An API call would be highly preferable, as it would give access to just this one feature.
The second option, one that I implemented in PsManager from the first time I found out about this issue, is the option to not resize to a memory level below actual usage + cache. This was even the default setting up until the latest release (changed in 0.6.1). It avoids the reboots, but the downside is of course that you’ll be reserving more memory than you really need, which leads to a higher cost of your VPS.
The third option is a dirty one, by having the script temporarily reserve a significant amount of memory, the cache can be reduced because the OS will free up cache memory to make it available to the script. Then the program would release that memory prior to making the resize API call. I prefer not to have to use dirty tricks like this, but since I’ve been waiting so long for a cleaner solution, I may decide to implement this anyway.
p.s. The purpose of this post is twofold, the first as an explanation to anyone who encounters this problem. Which saves me from explaining this again and again by e-mail, instead I can now just point people to this thread. The second purpose is the hope that Dreamhost might decide to fix this in their resize robot or provide the API call. This is after all Dreamhost, and they do in my experience actually listen to their users.