GridPane Server with High Load and Overlapping Cron Jobs

Introduction

I had a GridPane server with a single site that was showing signs of high resource load, specifically CPU, based on Netdata/Monit. Digging deeper I found that the cronjobs were overlapping for some reason.

GridPane WordPress Cron – GP-Cron

A nice feature of GridPane platform is their WordPress cronjob feature called GP-Cron, you can read more about it here.

Ubuntu 20.04 & 22.04: WP-Cron and GridPane’s GP-Cron | GridPane

WP-Cron is how WordPress handles scheduling time-based tasks such as checking for updates and publishing scheduled post. At GridPane, we have GP-Cron…

gridpane.com

Here is the default GP-Cron settings on Ubuntu 24, first we’ll look at the command.

gp site domain.com -gpcron-on 5 -fuzziness 270

Here is the resulting cronjob code.

*/5 * * * * domain21004 sleep $(/usr/local/bin/lib/randomish.sh 270); echo "$(/bin/date) >>> >>> >>> >>>" >>/home/domain21004/home/domain21004/sites/domain.com/logs/gp-cron.log; /usr/local/bin/wp cron event run --due-now  --path=/var/www/domain.com/htdocs >>/home/domain21004/home/domain21004/sites/domain.com/logs/gp-cron.log 2>&1; echo "$(/bin/date) <<< <<< <<< END" >>/home/domain21004/home/domain21004/sites/domain.com/logs/gp-cron.log

The GridPane GP-Cron will run your WordPress site cron at an interval of your choosing. The first release had issues with overlapping and no logging in Ubuntu 20, but in Ubuntu 22 this was resolved with random cronjob starts and logging.

Here are the new options when enabling the GridPane WordPress Cron

-fuzziness: This adds per-second randomization so that GP-Cron is executed at random intervals instead of all at once on the minute. This is now active by default.

-sec-delay: This allows you to set your cron to delay a specific number of seconds, giving per second control over when GP-Cron executes.

You have to make sure that you configure these properly, otherwise you might overload your server or have overlapping crons.

Overlapping GP-Cron WordPress Crons

The term overlapping in this instance is when a cronjob for a single site starts but never finishes before it starts yet again. This can occur on sites that have longer than typical cronjob run times, or if there is an issue with the cronjob completing successfully.

In the specific instance I was investigating, the GP-Cron cronjob was set to run every minute with no fuzziness set. This is the equivalent to the following command

gp site domain.com -gpcron-on 1

Which resulting in the following cronjob code.

*/1 * * * * user1234 sleep $(/usr/local/bin/lib/randomish.sh 0); echo "$(/bin/date) >>> >>> >>> >>>" >>/home/user1234/home/user1234/sites/domain.com/logs/gp-cron.log; /usr/local/bin/wp cron event run --due-now  --path=/var/www/domain.com/htdocs >>/home/user1234/home/user1234/sites/domain.com/logs/gp-cron.log 2>&1; echo "$(/bin/date) <<< <<< <<< END" >>/home/user1234/home/user1234/sites/domain.com/logs/gp-cron.log

This can be avoided by checking if the cronjob is already running. Unfortunately, the GP-Cron doesn’t do this. So, if you misconfigure the GP-Cron, you can end up with overlapping crons that simply stack up and cause a resource load on your server.

Solution? Update your GP-Cron Settings

The solution is simple, update your GP-Cron settings to add more fuzziness and delay so that they don’t overlap and stack. You could start with the GridPane default, which again from above is the following

gp site domain.com -gpcron-on 5 -fuzziness 270

If you’re still having issues you can increase how often the cronjob runs from 5 minutes to 15 minutes or the fuzziness to a higher amount. But beware of the following when using fuziness as there is a restriction based on a formula.

Maximum Fuzziness Setting

We will only accept fuzzy second values based on this formula:

max_fuzzy_seconds=$((minute_freq * 60 - 30))

For example:

10 minutes: 10 x 60 = 600 seconds. 600 – 30 = a max total of 570 seconds.

3 minutes: 3 x 60 = 180 seconds. 180 – 30 = a max total of 150 seconds.

7 minutes: 7 x 60 = 420 seconds. 420 – 30 = a max total of 390 seconds.

Suggested Improvement to GP-Cron

Implementing some sort of check, such as file locking, which would be one solution. Here is a simple example, I’ve shortened the code so that it’s easier to visually digest.

*/1 * * * * user1234 flock -n /tmp/wp-cron.lock /usr/local/bin/wp cron event run --due-now --path=/var/www/domain.com/htdocs >> /home/user1234/home/user1234/sites/pixm.com/logs/gp-cron.log 2>&1

This would ensure that the cronjob doesn’t run until the last cronjob is finished. In some circumstances, a cronjob might run a job once a day that takes more than 5 minutes, once complete the cronjob would run for less time as the large action has completed.

Another suggest is to track how long the cronjob is running, however that is not a requirement to resolve the current issue. It simply provides more data.

Alternatives – ManagingWP WordPress Cron Shim

There is another alternative to GridPane’s WordPress Cron and that’s the script that I’ve developed and called WordPress Cron Shim. It’s essentially a bash script that does all the work for you. It has a number of features, including file locking and tracking cron runs.

wp-shelltools – Managing WP

I made wp-shelltools because I was working on a number of different servers and platforms and needed a way to bring my “tool bag” with me to help with some

managingwp.io