Is this memory usage normal in Ghost? 512Mb Droplet

Posted August 2, 2016 5.8k views

I run in a 512 Mb droplet with Ubuntu 14, I installed it via the one-click installation process and recently updated Ghost to the latest version (0.9 I think).

When I keep logging into my SSH I see that the memory used is around 45% and that I’ve used around 15% of my 20 GB. I already ran the top command and when the Ghost process casually pops out I see it consumes around 0.4% and 9% (when I go to the ghost admin panel) of CPU and around 30% of “%MEM”.

A couple of hours ago my droplet spiked to 130% with 20 active users I got from StumbleUpon, not sure if that caused the spike because it handled the 20 users well for like 30 minutes until it spiked and couldn’t log in via SSH and had to turn it off and on again from the DO droplet panel (hard reset).

This is the data I just took with 1 active user (me):

Welcome to Ubuntu 14.04.3 LTS (GNU/Linux 3.13.0-71-generic x86_64)

 * Documentation:

  System information as of Mon Aug  1 23:38:43 EDT 2016

  System load:  0.0                Processes:           84
  Usage of /:   14.0% of 19.56GB   Users logged in:     1
  Memory usage: 45%                IP address for eth0:
  Swap usage:   0%

  Graph this data and manage this system at:

113 packages can be updated.
67 updates are security updates.

New release '16.04.1 LTS' available.
Run 'do-release-upgrade' to upgrade to it.

No mail.
Last login: Mon Aug  1 23:38:44 2016 from

Is that 45% memory usage normal? Should I add SWAP (I actually added a 2gb swapfile before because I couldn’t install the npm dependencies [process killed] before and removed it afterward) file or migrate to a brand new 512 Mb droplet? It runs with Nginx and I have nothing else installed, just ghost and Nginx. Should I update Ubuntu? I also got a terminal mail that the DB was blocked (though it may not be related).

1 comment
  • I have the same issue with a ghost droplet for my Ghost blog. Every few days it shuts off and causes 502 Bad Gateway error such that I have to ssh in and restart ghost. Any help would be appreciated!

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Submit an Answer
1 answer

That memory usage is normal. Running nginx with Ghost is great because nginx has a very small memory and CPU foot print, but every time you receive a visitor to your blog it will fire off other processes and that can cause your memory or CPU usage to increase.

The 512MB droplet is great for testing and development work, but if you are already in production you should probably consider upgrading to a 1GB or 2GB droplet especially if you are seeing latency or issues with logging in with 20 concurrent users.

The good news is that with a larger droplet you will get a lot more overhead so you’ll be able to handle much more traffic without an issue.

  • Thanks for the reply. The main issue was that my site kept stopping every 5 hours because of an unusual CPU spike in the graph panel (100%) and the disk graph and bandwidth graph didn’t show any spike during that period that the CPU was at 100% (cases in which I had to reboot the server).

    I migrated to a 5 USD droplet again in the SF 2 area and let’s see if the new IP helps. If not, I’ll take your advice and upgrade to a 10 USD droplet, the part that baffles me is that some bloggers said the 5 USD droplet was enough to handle a 20K monthly unique visitors Ghost instance.

    • That’s possible because there are 86,400 seconds in a single day so receiving 20,000 visitors in a month is no where close to one connection per second. However that 20,000 maybe split across the entire month, or all happen in the same hour. So the amount of concurrent connections is the limiting factor.

      The more concurrent connections you have the more likely you are to encounter limitations on the smaller 512MB droplet, so it’s not so much the total for the month, but what is the maximum number of concurrent connections they handled.