Not too long ago, I was coasting along, enjoying the benefits of moving my WordPress site from Bluehost to Amazon Lightsail. It was a good move as I had much more control over my site and latency was at its lowest. Little did I know that The Travelling Squid would experience downtime out of a sudden, caused by no action on my end. Eventually, I managed to resolve it with help from AWS Support. Here are some solutions you could adopt in the event your Wordpress site on Lightsail goes down due to insufficient disk space.
It was Sunday afternoon in Singapore when I was notified of the downtime, and I wrote in to AWS Support seeking their quick assistance. (Thankfully, my month-long subscription to the AWS Support Developer plan was still valid). AWS Support responded within 24 hours, on Monday afternoon. They ran some checks to ensure that the AWS/networking side of things were working correctly. Then, they asked me to run some commands via SSH to my Lightsail Instance. When I accessed the instance on Lightsail, it was still running.
How to fix it: WordPress site on Lightsail goes down due to insufficient disk space
1. Stop, start and restart your instance
AWS Support asked that I try to restart, stop and start the instance again. You can do so via the instructions here.
2. Check if your Apache Server is running. If it’s not, restart it.
To check if your Apache Server is running, you can use the following commands.
$ sudo /opt/bitnami/ctlscript.sh status apache
To restart your Apache server, use this command:
$ sudo /opt/bitnami/ctlscript.sh restart
When I entered the commands, I received the following errors on my website (see screenshot above). Alas, it seems that there was a lack of space on my drive.
3. Solution: Increase disk space by getting a bigger plan or delete excess files
To address this issue, AWS Support suggested that I upgrade to a bigger plan to address the lack of disk space. In a bid to get my site up and running soon, I made a switch to the 60GB instance from Amazon at USD10 per month, after mapping the snapshot of my site to a bigger instance. After doing so, The Travelling Squid was up and running again. [Do not that moving your site to a bigger instance is a one-way process. You will not be able to map a snapshot of a bigger instance to a smaller instance thereafter.]
I decided to do some housekeeping, to determine if there were excess files which I could remove. According to AWS Support, there could be excess backup files or plugins in the file location: /opt/bitnami/apps/wordpress/htdocs/wp-content.
AWS Support also asked that I key in the following commands, to determine the disk space currently being occupied:
a) Command to list all the files system partitions and data utilization
$ df -h
b) Command to view file sizes in individual folders. For example, my WordPress site is built on the WordPress platform which is pre-installed in the instance. The WordPress files will be under [ /opt/bitnami/apps/wordpress/htdocs ]
$ du -sh [insert file location] $ du -sh /opt/bitnami/apps/wordpress/htdocs
The ‘find’ command is also useful to list files which are of a big file size. For example, the command below will find files with a size more than 50mb.
$ find / -xdev -type f -size +50M
When I entered the command, it revealed that several files taking up disk space included a) a duplicate of a video I had uploaded to my site some time ago (it was 171mb) and b) several backup WordPress files which I had on my website when I migrated the files over from Bluehost.
To delete them via Filezilla, I first had to enable the necessary permission to access the file location. Such a command was covered in an earlier post on migrating my WordPress site from Bluehost to Amazon Lightsail (see below). You can also refer to this Bitnami documentation for more details on enabling permissions for the necessary file locations.
$ sudo chown bitnami TARGETFOLDER $ sudo chmod +w TARGETFOLDER
After enabling the necessary permissions to the folders, I proceeded to delete the backups which were about 6-7gb in size. There was no longer a need for me to create backup files with WordPress as Amazon snapshots on Lightsail had proven to be a very effective backup tool.
I found that my initial site was about 43gb in size, exceeding the allocated 40gb provided under my current plan. There were about 3 back-up files which were 6gb in size. After deleting them and the duplicated video, I managed to bring the file size to about 23gb, which was under 40gb.
I then decided to stick with my original 40gb plan at USD5 per month, and map the original snapshot of my 40gb instance to a new 40gb instance. I repeated the steps to remove the excess backup files, and soon, The Travelling Squid was up again.
4. Removing the plugin which automatically generates back up files
After resolving that issue, I went away for a couple of days and returned to find that my site’s disk usage had increased to 29 gb from the previous size of 23 gb. I realised it could be a WordPress plugin which was automatically generating back-up files. Through the WordPress admin page, it was indeed the Backup plugin which was generating both Database and File backups. (I had initially used this plugin to backup files for my Bluehost site). As I no longer required this plugin, I deactivated and deleted it and other back-up plugins, as these may cause unnecessary files to be generated.
5. Compressing Apache access and error logs
AWS Support also taught me how to compress log files via the commands below, should I find any log files which are consuming more disk space than necessary. The engineer shared that the Apache access logs and error logs will be under the location [ /opt/bitnami/apache2/logs ]. The steps to compress Apache access and error logs are as follows:
a) Elevate user privilege to root
# sudo su
b) Enter the folder where the log files exist
# cd /opt/bitnami/apache2/logs
c) Compress the file error_log to error_log.tar.gz and remove the original “error_log” file
# tar -zcvf error_log.tar.gz error_log --remove-files
d) Compress the file access_log to access_log.tar.gz and remove the original “access_log” file
# tar -zcvf access_log.tar.gz access_log --remove-files
It was a straightforward process and very useful especially if you’re planning to run the site over the long term.
6. Deleting excess photo images generated by WordPress
During my house-keeping of files on my WordPress site, I realised that WordPress has a tendency of creating copies of images when I upload photos to the site. When one photo is uploaded, about 5-9 sizes of the images are created.
I read from various articles that this is not completely a bad thing, as the various image sizes are generated based on the requirements of your site’s theme. For example, The Travelling Squid requires an image size for thumbnails to related posts which is a (150×150) sized image, and preview images to the post on my homepage, which is (332×205). You can delete the files by bulk via Filezilla by searching for the files by their size. I’ll write more about that in an upcoming post.
The Travelling Squid’s Take – Wordpress site on Lightsail goes down due to insufficient disk space
This experience taught me the importance of house-keeping. It also reminded me of the need to keep track of one’s disk space usage and to remove extra files and unnecessary WordPress plugins. To avoid downtime, I’d encourage you to regularly check your disk space usage. If it’s constantly pushing close to the limit, paying for high disk capacity might be a reasonable option. On my end, I’m also looking at how to compress BIN log files as those have a file size of more than 50mb. Will write about that if I succeed!