Tong Family

Well, as I told you I did a bunch of WordPress work last week to keep the disk from overflowing, but this week, I’m finding that WordPress is stalling at 100% CPU utilization for minutes after a post, so time once again to figure out what is wrong. I did get the general performance down from 9 seconds to 3 seconds just by installing redis object caching and other tricks, but this is something different.

The first thing I noticed is that JetPack Monitor would report the site is down during the week. And then today, I noticed that a post took five minutes and that the site went offline. To debug this, I went to the internet and learned about

1. htop. This is a graphical utility that you turn on when you log in to the console. Digital Ocean makes this easy since they support a console from their interface. The first thing that I noticed performance-wise is that the CPU had spiked to 100% with a huge load. In looking at what is going on, I saw two things, the first is that MySQL was running at 25% and also there were a bunch of Apache2 jobs running at 15-25% utilization continuously. That meant my CPU was pegged at 100% most of the time with a 3x load average. Memory wasn’t too bad at 722MB used of 1GB, but I did see that my swapfile had a high of 1GB so that was a little concerning.
2. WP Server Stats. I installed a plugin called WP Health Stats that gives me this data from the WordPress Administrative interface. As an aside, the new dashboard with drag-and-drop widgets is so convenient. I can see what Monster Insight, All-in-SEO, and other things are thinking very easily.
3. In looking at how to debug WordPress slowness
4. WP-Crontrol. I also installed the WP-Crontrol plugin to tell me what is running when you post a message. WordPress will run background jobs like ActivityPub after each post which can be very slow. So maybe that is it. The confusing thing is that when I looked at that plug-in, the logs didn’t show a lot of activity. You go to Settings > Cron Schedules and can see what is running. Unfortunately, I didn’t see much there.
5. Decalog. I also installed a log manager so again I don’t have to dig deep into what is going on from the command line. You can even administer the logger from the terminal command line with f

Theory: It could be ActivityPub or some heavy job

Turns out that you have to run quite a bit to make a WordPress site look dynamic and many of these things are done after a post. So that’s one theory, but I’m not sure, but the server is running very hot right now. In the worst case, I’ll reboot it, but the search goes one.

General high CPU utilization diagnostics: Query Monitor and All-in-One SEO

Well, the first thing wasn’t super helpful, but if you switch to MariaDB and Litespeed instead of MySQL and Apache this should speed things up if you get more RAM and so forth. For me, that’s not that helpful since I’m moving to a static site generator anyway and this is a very low-traffic site.

CPU hogging plugins. This seemed more promising, but basically, if you are trying to figure out what plug-in is taking time, you can install Query Monitor to figure this out by going to that plugin and looking at Queries > Queries by Component and it shows that All-in-one SEO is doing most of the querying. So it could be that this plug-in is the thing slowing things down. We will have to see. I’m going to deactivate it and see what happens.