[Snapshot Pro] Snapshot is running a lot of Cron Events.

I have resources (CPU/memory) issues lately with my server, and after investigating cronjobs using wp-crontrol plugin. I’ve noticed that Snapshot is running the most Cron events on my server. Although. I am not setting Snapshot to run on schedule.

  • Adam Czajczyk
    • Support Gorilla

    Hi logan

    I hope you’re well today and thank you for getting in touch with us!

    I’ve accessed your site and I can see that currently there’s no Managed Backups configured for the site and that “snapshot” that exists there is a “once off”. The Snapshot plugin does register CRON schedules anyway but in case like this they are really not doing anything particular – as they don’t have anything to do.

    I mean by this that if e.g. “snapshot-5minutes” schedule is run, it simply is triggered and “sees” that there’s nothing to be done and terminates. That’s pretty much all and it should not affect server load in any considerable way/level.

    However, I’m wondering about something else – related. You mentioned that with help of SiteGround you were able to identify that it’s Snapshot’s cron tasks what’s using up server resources. Would you be able to share more details of what they told you exactly?

    There’s a WP Crontrol plugin installed and a look at the “Cron Events” list suggests that there’s actually an issue with cron and in fact no tasks seem to be executed at all since at least Aug 29th. So that’s over two weeks and if what Crontrol shows is true – and they were not executed – it would mean that

    – it cannot be a reason for server resource usage
    – there’s also some additional issue that needs to be investigated that actually breaks the cron all togehter (which actually can result in other issues; including resource usage)

    Best regards,
    Adam

  • Logan
    • The Incredible Code Injector

    Hi, Adam,

    Thanks.
    Let me clarify – SG did not single out any plugin, just that the largest requestor (by IP) to the server was the server itself.

    Then posted a few log examples from alliancewellness:

    109.199.113.167 – – [13/Sep/2019:09:49:54 -0500] “POST /wp-cron.php?doing_wp_cron=1568386194.2994799613952636718750 HTTP/1.0” 200 – “http://alliancewellnesscenter.org/wp-cron.php?doing_wp_cron=1568386194.2994799613952636718750” “WordPress/5.2.2; https://alliancewellnesscenter.org
    109.199.113.167 – – [13/Sep/2019:10:02:48 -0500] “POST /wp-cron.php?doing_wp_cron=1568386968.2851250171661376953125 HTTP/1.0” 200 – “http://alliancewellnesscenter.org/wp-cron.php?doing_wp_cron=1568386968.2851250171661376953125” “WordPress/5.2.2; https://alliancewellnesscenter.org
    109.199.113.167 – – [13/Sep/2019:15:01:33 -0500] “POST /wp-cron.php?doing_wp_cron=1568404893.9795870780944824218750 HTTP/1.0” 200 – “http://alliancewellnesscenter.org/wp-cron.php?doing_wp_cron=1568404893.9795870780944824218750” “WordPress/5.2.2; https://alliancewellnesscenter.org
    109.199.113.167 – – [13/Sep/2019:15:01:35 -0500] “POST /wp-cron.php?doing_wp_cron=1568404895.9299540519714355468750 HTTP/1.0” 200 – “http://alliancewellnesscenter.org/wp-cron.php?doing_wp_cron=1568404895.9299540519714355468750” “WordPress/5.2.2; https://alliancewellnesscenter.org

    Which got me thinking ‘yea, what cron jobs are running on the alliance site?’

    So I installed the wp-crontrol plugin and was surprised with how many are ‘snapshot’ related and then reached out to you.

    In sum, I’m not suggesting Snapshot is problematic here, just that the majority of cron jobs related to ‘snapshot’ (even if it’s just to ‘wake up and check’:wink: in crontrol is eye opening and (at least mildly) of concern.

    Especially because I host several website on the server (its their Cloud platform, not the shared hosting. So middle tier, their version of VPS).

    From what I can tell, however, cron is working so why do you say “there’s also some additional issue that needs to be investigated that actually breaks the cron all togehter (which actually can result in other issues; including resource usage)”?

    Help me find them please!

    Thank you!

  • Adam Czajczyk
    • Support Gorilla

    Hi Logan

    Thanks for your response and sharing part of that cron requests log.

    It is actually expected that the “largest requester” in this case will be the site/server itself. The way WP cron works is that when the site is visited, every now and then WordPress executes cron by making such POST request (as listed in the log) so naturally it will be coming from site’s IP.

    An alternative option is to disable WP Cron and use real server cron instead but that would still also mean that the requests would go from your own server – so that’s perfectly fine and expected.

    It’s also nothing unusual that there’s many of those because even if there was no Snapshot cron schedules registered, there’d still be at least an “hourly” schedule and the requests would be there.

    Then the question is whether the request causes load on server or not. That’s mostly related what it does actually execute. First thing such schedule does when triggered is to check whether there are even events that should be triggered. If yes, they are triggered and depending on what they do, they might cause higher or lower load on server. If there’s nothing to do, the load on server should be pretty much unnoticeable.

    Now, getting back to the site. The log indicates that the “schedule” is run and that’s fine. But it also shows that all the requests result in “500” HTTP response code which actually means… they fail. The “-0500” string next to each time/date of request states that the “500 Internal Server Error” has occurred and that is indeed an indication that something’s not right. Furthermore, 500 error often does indeed reflects resource/load issues.

    Also, if you look at the “Cron Events” list form WP Crontrol plugin (at “Tools -> Cron Events” page) you’ll notice that there are many outdated events that should have been already run and completed – but they are overdue:

    So this together confirms that cron is not working quite as it should and yes – it may confirm that this has indirect impact on server resource usage. Not the cron itself but rather something “under the hood” that also causes cron requests to trigger 500 error.

    So the question is what exactly is causing that 500 error as if we will be able to fix that, it will also fix the cron schedule and should also help with resource usage.

    That being said, could you check three more things, please?

    1) check with your host if there’s any chance to increase “max_execution_time” for PHP; it’s currently set to 45 seconds which is rather low value and if only possible to increase, I’d recommend going somewhere closer to the 160-180 value (it’s a lot but a “safe value”:wink:

    2) try increasing WordPress memory limit; PHP on server currently allows up to 512M but your WordPress install is set to limit it to 128M; that usually should be enough but it won’t hurt (and may help) to increase it to e.g. 256M. To do so, make sure that there is this line in the “wp-config.php” file of your site

    define( 'WP_MEMORY_LIMIT', '256M' );

    3) finally, please enable WP debugging by adding following lines to the “wp-config.php” file, above the “/* That’s all, stop editing! */” line:

    define( 'WP_DEBUG', true );
    define( 'WP_DEBUG_LOG', true );
    define( 'WP_DEBUG_DISPLAY', false );

    Once they are there, wait a few hours (to give WP cron a chance to have multiple run attempts) and look into the “/wp-content/” folder of your site; If there’s a “debug.log” file there, please download it, upload to some file storage of yours (like your Google Drive or Dropbox account or similar) and share a direct download link to it with me here.

    Hopefully it will help identify the “core” of the problem.

    Best regards,
    Adam

  • Predrag Dubajic
    • Support

    Hi Logan,

    Apologies for the delay on this ticket.

    Sometimes due to the server configuration the log file can be placed inside the root WP folder and can be named error_log, can you see if you have anything like that?

    If there’s no log file still can you try replacing the code that Adam mentioned in #3 with below one and see if the logs are created after that?

    // Enable WP_DEBUG mode
    define('WP_DEBUG', true);
    
    // Enable Debug logging to the /wp-content/debug.log file
    define('WP_DEBUG_LOG', true);
    
    // Disable display of errors and warnings
    define('WP_DEBUG_DISPLAY', false);
    @ini_set( 'log_errors', 1 );
    @ini_set( 'display_errors', 0 );

    Best regards,
    Predrag

  • Adam Czajczyk
    • Support Gorilla

    Hi Logan

    Thanks for sharing that!

    Unfortunately, access log is not the same as debug log and while it does confirm that 500 status issue on cron calls, it doesn’t say much more. I’m actually a bit surprised that the debug.log doesn’t get created – with such 500 errors “something” should be logged in debug.log.

    I think we’ll need to get closer look at that and do some more tests as there’s clearly something that’s “breaking” some tasks that cron is attempting to trigger – which causes WP Cron to not be run properly and, ultimately, also is most likely directly related to resource usage issues.

    For this, I’d need to be able to access site and server directly so could you please provide me with access credentials?

    Note: Don’t leave your login details in this ticket.
    Instead, you can send me your details using our contact form https://premium.wpmudev.org/contact/#i-have-a-different-question and the template below:

    Subject: “Attn: Adam Czajczyk
    – Site login URL
    – WordPress admin username
    – WordPress admin password
    – FTP credentials (host/username/password)
    – cPanel credentials (host/username/password) <- this would be very helpful if available! - Folder path to site in question - Link back to this thread for reference - Any other relevant urls/info Kind regards, Adam

  • Logan
    • The Incredible Code Injector

    Checking again this morning I do see wp-content/debug.log which has these lines in it. I believe I may have been looking for error_log and/or just missed it before….

    [21-Sep-2019 04:27:19 UTC]

    [22-Sep-2019 04:45:13 UTC] PHP Notice: map_meta_cap was called incorrectly. The post type wpfeedback is not registered, so it may not be reliable to check the capability “read_post” against a post of that type. Please see Debugging in WordPress for more information. (This message was added in version 4.4.0.) in /home/alliancewellness/public_html/wp-includes/functions.php on line 4773

    [22-Sep-2019 04:45:13 UTC] PHP Notice: map_meta_cap was called incorrectly. The post type wpfeedback is not registered, so it may not be reliable to check the capability “edit_post” against a post of that type. Please see Debugging in WordPress for more information. (This message was added in version 4.4.0.) in /home/alliancewellness/public_html/wp-includes/functions.php on line 4773

    Interestingly, the plugin (wpfeedback ) in question is deactivated and I have posted a question to their support.

    Is that enough or do you still want access? If so, I will look into that.

    Thank you!

  • Adam Czajczyk
    • Support Gorilla

    Hi Logan

    Thanks for sharing the log. It still doesn’t seem to explain what’s happening but it is actually a “step further” as it at least seem to confirm that some “unexpected things” are going on.

    As for the “wpfeedback” – that might not necessarily be an issue of the plugin actually. The message only states that the custom post type “wpfeedback” is not registered and “something” is trying to use it. In this case, it’s somehow related to setting user capabilities so if not the plugin, it’s possible that there’s some custom code or maybe a user-capabilites plugin that tries to address that. Though that’s just an idea :slight_smile:

    But I think that I could still make use of the access that I asked for previously as it would give me a full insight to the site – sometimes “it helps to see” as you can spot something you wouldn’t even think of otherwise :slight_smile:

    Best regards
    Adam

  • Logan
    • The Incredible Code Injector

    sweet! good call it may not actually be their plugin. I found some new entries yesterday in debug.log with wpfeedback so (just now) deleted the plugin entirely and will check the debug.log file tomorrow.

    if I still have entries, I’ll navigate the cpanel access and post above.

    Thank you for the excellent support and communication!

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.