Blog web server upgrade

I have completed a simple upgrade to the little box that serves my blogs. I have increased its RAM from 16 gigabytes to 64 gigabytes.

I had observed some page loading slow-downs under some conditions recently. My quick review gave me the idea that some of the blogs processes might be a bit starved for memory. Too much of the system’s work seemed to be regularly swapped to virtual memory swap (SSD), a condition generally to be avoided.

The change in memory capacity and process configuration seems to have made the blogs a bit more responsive. However, it appears that most of the slow rendering I’ve noted relates more to Safari behaviour with the content of the site than with any shortcomings of my server hardware.

I’ve included some more detail below the ‘Read More’ fold for those who are interested.

What I observed

I visit my own blogs fairly regularly: several times a day at least. I noticed that my two small blogs (Words of the AgingGamer and Geek on a Harley) were rendering fairly quickly (e.g.: under 2 seconds) in Safari, but my main blog i.e.: this one was frequently taking four or five times that long.

Interestingly, the rendering of this blog seemed faster in Chrome and Firefox, but I think that has a lot to do with how these browsers handle incomplete page data. I’m not really sure about this, though: and I use Safari (the macOS default browser) most of the time, so that’s the behaviour I focused on.

I logged in to the server and invoked Linux ‘top‘ to look at process and memory usage. There I noticed that three of the four ‘core’ web server / blog services were all using more virtual memory that I’d like, and that swap consumption on the server seemed elevated as a result. The processes, of which multiple instances usually are running, are:

• valkey: valkey is an in-memory key-value data store that I have configured PHP/Wordpress to use for entity storage (redis)
• mariadb: mariadb is the modern mySQL database that WordPress uses to store all of its content management data
• php-fpm: php-fpm is basically the high-performance multi-threading version of PHP

I saw two problems during this initial observation: too much virtual memory being used by the key data processes (valkey and mariadb were both using 5+ GB of virtual memory) and too many instances (about 100) of php-fpm for the amount of RAM available. The data store and PHP processes together were trying to use somewhere over 30 GB of RAM on a system with 16 GB. Note that this level of consumption was with a server uptime of over 100 days, which is fairly typical for my blog server.

Initial configuration changes

I contemplated my options. My blog server is about 8 years old- it is a circa-2017 Intel NUC machine using an Intel Core i5 processor. So it probably wouldn’t hurt to upgrade the whole machine, but I’m not really wanting to spend that kind of money at the moment.

Adding more RAM would be cheaper than replacing the whole machine, and my observations showed that more RAM would likely help. And I could use the new RAM in a future new machine if I found that it didn’t have a positive enough effect on performance with the old processor.

I ordered some RAM based on this reasoning- see next section for details. I also made some changes to the configuration of each of the key memory-consuming processes to make them a bit less greedy for RAM. The changes I made were roughly as follows:

• valkey: reduced maxmemory setting to avoid consuming all available RAM e.g.: in /etc/valkey/valkey.conf
  • maxmemory = 8gb (originally 16 gb)
• mariadb: reduced innodb_buffer_pool_size and innodb_buffer_pool_instances to avoid consuming more RAM than physically exists e.g.: in /etc/my.cnf.d/mariadb-server.cnf
  • innodb_buffer_pool_size = 2GB (originally 8GB)
  • innodb_buffer_pool_instances = 4 (originally 8 instances)
• php-fpm: reduced the maximum number of instances of the the php-fpm process that can be launched e.g. in /etc/php-fpm.d/www.conf
  • pm.max_children=16
    • Note that each instance can use up to memory_limit RAM found in the /etc/php.ini file; in my case, memory_limit was 256 megabytes, so 16 children would consume up to 4 GB of RAM

Adding more RAM

The RAM in my web server NUC (Next Unit of Computing) is laptop memory, specifically DDR4 SODIMM packaging. The ‘official’ maximum memory for the Intel i5 NUC is 32 GB, but I read that 64 GB works fine. So that’s what I ordered: a kit consisting of two 32 GB SODIMM components (Kingston FURY Impact 64GB (2x32GB) 3200MHz DDR4 CL20).

I installed the new RAM without any issues and the computer booted up with 64 GB of RAM as expected. I then went back and revised the configuration to take advantage of the additional memory.

• valkey: increased maxmemory setting e.g.: in /etc/valkey/valkey.conf
  • maxmemory = 16gb
• mariadb: increased innodb_buffer_pool_size and innodb_buffer_pool_instances e.g.: in /etc/my.cnf.d/mariadb-server.cnf
  • innodb_buffer_pool_size = 4GB
  • innodb_buffer_pool_instances = 8
• php-fpm: reduced the maximum number of instances of the the php-fpm process that can be launched e.g. in /etc/php-fpm.d/www.conf
  • pm.max_children = 64

Note that these settings as a whole could theoretically consume all available physical RAM in the machine. I’ll check back periodically to see if I should make any adjustments to prevent excess swap/virtual memory use.

Post-upgrade observations

My initial observations of rendering performance of my site have been guardedly positive. All three of my blogs seem to render a bit more promptly, so the extra memory appears beneficial.

I have noted, however, that Safari still intermittently takes quite a bit longer than expected, and specifically longer than Chrome and Firefox browsers, to render Ubergeek Kelly’s World. I suspect that the browser behaviour plays a significant part in how ‘first contentful paint’ behaves. Getting Safari to be happier with my main blog may require some additional experimentation with something other than hardware.

On the plus side, more RAM never really hurts, and at least I didn’t go crazy and buy a whole new server!