Get Better Perfomance with Ghost Blog over ubuntu

November 23, 2015 797 views
Node.js Ghost Nginx Ubuntu

Im running a 10 dolars droplet with 5 ghost blogs over a nginx.

They are running ok BUT i see i got just 69mb left of RAM.

I created a swap file but those process (nodejs and ghost) doesnt seem to use it.

Do you guys have any tips on how to improve things so i could not run out of memory :)

1 Answer


Please run the following command from the CLI:

free -m

... and post the output in full (it's not long).


The swap file is not used by an application, so to speak, rather, the OS itself. In the event you've run out of RAM, the OS will then attempt to use swap. You can't (and wouldn't want to) assign an app to use swap over RAM.


That said, keep in mind that NodeJS requires RAM to run and each of the instances of Ghost require RAM to run (and function). While 1GB is effective for a few smaller websites, anything that requires a process to be long-running (such as a server instance powered by NodeJS), is going to consume more and more RAM over time. Very rarely will a single instance of anything only use a set amount of RAM indefinitely.

  • This is my free -m with 5 ghost instances running and a html website over a 10$ Instance
    total used free shared buffers cached
    Mem: 993 917 76 0 41 104
    -/+ buffers/cache: 771 222
    Swap: 4095 26 4069

    • @leo

      Of your 1GB RAM, you're physically using just over 800MB (Total - Cached), though swap is barely being touched (at least at the time the command was executed).

      What that would indicate is that the 5 Ghost blogs are truly using the RAM (or, at the very least, reserving it).


      There's a few things you can do that may reduce RAM usage.

      Reduce Requests

      The first group of assets that I target on the front-end are JS & CSS files. If you're loading 5-10 JS files and 2-4 CSS files each page load and these files have not been minified / compressed, this can do a number on actual resource usage. This is due to buffers that are required to process there request (i.e. reading the contents of the file). The larger the file(s), the larger the buffer and the larger the resource usage (which affects RAM and CPU).

      You should aim for a single CSS file (ideal) and as few JS files as possible. Due to variances in code, not all JS will combine together as a single file and in many cases, the order of JS code is important, so for JS, this is a trial and error process.

      Compress each of the JS files using a minifier service, or by using a NodeJS plugin. This should be done once, not on-demand (i.e. compressing and minifying should not be performed on each request); ultimately prior to uploading.

      Once you've compressed and minified your CSS and JS, make sure it's cached so that you're not repeatedly serving it fresh. How you'd go about this really depends on how you've setup NGINX.

      If you'll post your NGINX core configuration (nginx.conf) and your server block configuration (yourwebsite.conf), I'll be more than happy to take a look at it and make some suggestions.

      Your core NGINX configuration file should be located at:


      .... or your custom location :-).

      Use a CDN

      Offloading assets to a CDN can lighten the load, speed up delivery and reduce resource usage. MaxCDN is an excellent choice (I use them often), though realistically, any CDN would be better than no CDN :-).

      You'd still want to compress and minify your files before serving them, of course.

      Optimize Code / Optimize Theme / Reduce Plugins

      If you're able to modify code, HTML etc, optimizing the code and theme would be one of the best places to gain the most benefit. Reducing plugins (if any are installed) is also one way to reduce resource usage. Like WordPress (PHP/MySQL), the more plugins you're running, the more resources you'll use as it's more code to process, more things to do etc.


      If you've compressed & minified your files and, after we take a look at your NGINX configuration, you're still not seeing a drop, then upgrading to a 2GB Droplet may be the best overall step -- especially if you're not able to modify code.

Have another answer? Share your knowledge.