- Support forum for the WooCommerce Scheduled & Automatic Order Status Controller.
- This topic has 0 replies, 1 voice, and was last updated 1 year, 2 months ago by Shawn Welch.
- AuthorPosts
- October 6, 2023 at 8:03 am #125420Shawn WelchParticipant
This is directly from my host regarding this plugin:
If there was a database bottleneck, we would expect to have seen some more database-side utilization instead of that large server-side memory spike; we unfortunately don’t have much information on what in the cron job’s execution was taking up that large amount of memory, but it seems possible there may be something in the cron job’s code causing a memory leak, or perhaps just running the job inefficiently:
This is from our manual run of the cron job, which would not be limited by the site’s maximum PHP memory amount. Checking our cron runner’s logs, we can see that for the automated runs, the cron job seems to hit the site’s maximum PHP memory value, causing a fatal PHP error during the execution of the
alg_wc_order_status_rules_<wbr />process_rules
job:2023-10-04 03:41:47 UTC - Starting cron run 2023-10-04 03:41:47 UTC - Running command: /usr/bin/docker exec --user 33:33 customer-webconfig-app-42823-1 php /httpdocs/pagely-cron.php 'e2mfitness.com' '/wp-cron.php' 'ohio-halcyoncreativeagenc.<wbr />vps.pagelyhosting.com' '600' Simulating request to: e2mfitness.com/wp-cron.php Deprecated: File wp-db.php is deprecated since version 6.1.0! Use wp-includes/class-wpdb.php instead. in /wordpress-versions/6.3.1/wp-<wbr />includes/functions.php on line 5665 Running 1696388680 wp_umbrella_error_check_run_<wbr />queue Running 1696388720 ssp_cron_hook Running 1696388804 automatewoo_five_minute_worker Running 1696388887 jetpack_clean_nonces Running 1696389104 automatewoo_thirty_minute_<wbr />worker Running 1696389104 automatewoo_fifteen_minute_<wbr />worker Running 1696389175 wc_gc_hourly Running 1696389909 objectcache_prune_analytics Running 1696390240 wp_umbrella_task_backup_run_<wbr />queue Running 1696390243 automatewoo_events_worker Running 1696390250 action_scheduler_run_queue Running 1696390262 alg_wc_order_status_rules_<wbr />process_rules Fatal error: Allowed memory size of 2147483648 bytes exhausted (tried to allocate 20480 bytes) in /pagely-plugins/redis-cache-<wbr />pro/src/Connections/<wbr />Connection.php on line 90 Fatal error: Allowed memory size of 2147483648 bytes exhausted (tried to allocate 20480 bytes) in /wordpress-versions/6.3.1/wp-<wbr />includes/class-wp-fatal-error-<wbr />handler.php on line 74 2023-10-04 03:42:19 UTC - Complete
This would explain why the cron job does not seem to bring down the server when run automatically, as it gets limited by the maximum PHP memory setting, but may also explain why it takes a long time to run, if it’s this limited by server memory. Raising the PHP memory limit doesn’t seem to be a viable option either, since as we saw from manually running this cron, without a memory limit it would take up all of the server’s memory to run.
At this point, one thing we could suggest would be to get in touch with the plugin’s developer, to double check what’s the expected amount of memory it would take to run this cron job, as the amount used from what we have seen above doesn’t look right. It’s possible that usage could be from a memory leak or similar bug, or perhaps something the developers may have a fix or workaround for, as well.
- AuthorPosts
- You must be logged in to reply to this topic.