We have come across a few instances now where a module that was not written correctly, and that made use of the Magento Cron framework caused MySQL to stop responding. When MySQL stops responding then it basically crashes Magento.
Tell tale signs in various logs point to the end effect, but not the root cause. You’ll see stuff like MySQL went away… MySQL connection lost… or Magento reports with lines like this:
{"0":"SQLSTATE[HY000] [2002] No such file or directory","1":"#0 \/var\/www\/magento\/vendor\/magento\/zendframework1\/library\/Zend\/Db\/Adapter\/Pdo\/Mysql.php(111):
Watching top from the command line points to MySQL consuming way too much CPU and Memory.
The root cause is actually NOT MySQL. MySQL just can’t keep up and ends up exhausting memory, cpu, and even drive space.
Most of the time it comes back to Magento’s use of cron!
Quickly checking the cron_schedule table in the database will help spot the problem and the offending module(s).
You’ll see a lot jobs stuck in the pending state, and perhaps thousands of records. A quick temporary relief is to just empty the table of all jobs, but this may not fix the core issue.
Best way to tackle this issue is to identify the offending module and disable it. Then reach out to the author and ask for a fix. Simply using another module like MageMojo’s Cron Module to circumvent Magento’s Cron system will let authors of buggy code continue to impact hundreds of systems without accountability.
Holding software vendors to a higher standard is important, because the Magento community as a whole depends on high-quality plugins.
Crontab Adjustments
If and when you change a cron from the Ubuntu crontab, make sure you reload it:
sudo service cron restart
Verify it with
sudo service cron status
Glad to shed some light on a common, but yet mysterious cause of Magento gremlins.
Oh, and if you are still crashing, and using 2.4 ~ 2.4.1 then check out this bug.
~ Lead_Robot