Tong Family

OK, so after I got the performance of WordPress up to decent with the help of redis and other tricks, this site went from a horrible 9 seconds to a very decent 1.5 seconds. But, I did find that it would become unavailable 4-6 times a day. I thought this was because I had exceeded 100% CPU and because of some plugin. But, I was wrong. The answer is that Redis needs a max memory and policy for kicking things out of memory that is not the default.

Redis error on the home page

Well, the first hint that I was wrong was the error that on the home page, could not connect to the redis database. This is the in-memory database that caches MySQL queries to improve performance

Redis default does not work for low-memory systems

The default for Redis set in /etc/redis/redis.conf is there is no maximum memory which means that if the system runs out of memory, then Ubuntu will end the process and this causes WordPress to lose its redis connection which then causes redis to automatically restart. That’s why I was seeing 20 minutes of unavailability, so the solution is to change the settings.

Looking at the logfile

So onto checking out /var/log/syslog and I saw that redis-server was stopping all the time. That was a great hint!

The first try is to set maxmemory

So trying to see maxmemory seemed like a good idea. Note that it takes a long time to service redis so instead of doing that it is easier to run redis-cli and change settings dynamically:

redis-cli
auth <your password>
config get maxmemory
# to see what it is set
config set maxmemory 1gb
config set maxmemory-policy volatile-lru

Then when it looks like it is right and running, you can edit redis.conf and restart the service. I tried a random cache policy volatile-lru because it sounded good, but it turns out that this also needs the TTL set on keys, and if you don’t have that set, then the thing crashes (see below).

Swapfile settings on low-memory machines

A long time ago, I had set up a swapfile for my el-cheapo 1GB virtual machine and made it 3GB worth to prevent it from crashing, but it does make it super slow if you access it.

The first settings didn’t go well, smaller memory and allkeys-lru needed

The first setting I tried was to set maxmemory=1gb. Turns out by the way that although it says it only understands bytes, it does understand gb and MB which is nice. But I got a strange message:

OOM command not allowed when used memory > 'maxmemory'

The problem looks like a misconfiguration so I tried maxmemory-policy=allkeys-lru and this seemed to work.

The second thing is that with only a 1GB machine, trying a 1GB cache seems very large and going back to a swap based cache kind of defeats the purpose, so I moved it to a 256mb maxmemory and it seems to work.

The last step JetPack no longer connects

OK, the final step to getting everything running is that JetPack and WordPress were no longer connected even with everything running. The recommendation of disconnecting and then reconnecting JetPack from the website admin console worked great.