Get Your Website Up and Running on Ghost with Workarounds
“Hey, look what I made!” Addressing a friend, I triumphantly said, “It’s online. Just open the link!”. I was very proud of my work. After a few evenings of frantic work, I finally had my little project ready, and I was ready to show it to the world.
“But I don’t see anything!” My first user replied showing a hint of doubt. “Screen is blank.” I was amazed. I felt betrayed and vulnerable. My wonderful personal website was down after only a few hours, and I have no idea why. This was a situation I could not tolerate.
My personal blog Ghost, an open-source content-creation platform. I wanted to go for a self-hosted solution, so I instantiated a small EC2 instance with only 1GB of RAM (yes, it’s included in the AWS free tier, and yes, I’m a peon) and Set up my blog on it. I published a few posts, took a cool picture of myself under the Tour Eiffel, and set out to dominate the blogging scene. Little did I know that my small website would be shut down within a few hours.
In the heat of the moment, I restarted the EC2 instance, and in no time, I was able to show my website to my friends again. However, this issue proved particularly sticky: Like a mischievous marionette, something was going wrong in my (virtual) house and causing trouble every few hours. But who was the culprit? Of course, traffic spikes were out of consideration: nobody knew about this website, and the page hadn’t been indexed yet. According to the AWS console, CPU usage seemed pretty stable, and I also had a decent credit balance. The most reasonable conclusion at this point was that Ghost was running out of RAM for some reason.
After searching through several blog posts and user groups, I found something interesting. Some users have noticed that Ghost can run on 1 GB of RAM, but from time to time it kills itself to death. The reason for this is still not clear (someone blames Node.js memory leaks, I wonder picture). On my part, I had no intention of changing the instance type to buff its specs and was not particularly inclined to delve deeper into the issue.
Once an intuition came to my mind. I reached over to the EC2 console, and I confirmed my guess: I only had 1GB of memory, but I was sitting on an 8GB SSD. “Well,” I thought, “maybe the default change The division is too small. let’s watch.”
$ free -m
total used free
Mem: 941 870 71
That’s right. Perhaps surprisingly to the tech-savvy reader, no swap partition was defined in the virtual machine. After gathering this information, the solution was at my fingertips.
First, I would create a swapfile with
dd command (also referred to as friendly
sudo dd if=/dev/zero of=/swapfile bs=128M count=8
By choosing eight blocks of size 128MB each, I would have, at this point, 1GB of extra memory at my disposal. At this point, let’s give proper read and write permissions to the swapfile:
$ sudo chmod 600 /swapfile
It is also necessary to tell Linux to create a swap area:
$ sudo mkswap /swapfile
Finally, I can enable the swapfile:
$ sudo swapon /swapfile
After running these commands, I felt alive with plenty of memory in my VM:
$ free -m
total used free
Mem: 941 411 530
Swap: 1023 491 532
I wanted my instance to remember my decision to create and use a swap file on start-up. To instruct it to do so, it is necessary to add the following line to
/swapfile swap swap defaults 0 0
One can say that relying on swap file is a cheap solution. To me, this is a real life cheat code.