Conversation
supportHI there passed week or so noticed Maximum simultaneous queues already in progress (2 queues). No additional queues will begin processing until the current queues are complete. For example now i have this snippet cause the ques piled up on past due like crazy. add_filter( ‘action_scheduler_queue_runner_concurrent_batches’, ‘tg_custom_concurrent_queues’ ); function tg_custom_concurrent_queues( $concurrent_batches ) { return 2; // Bumps max simultaneous queues from 2 to 4 } add_filter( ‘action_scheduler_queue_runner_batch_size’, ‘tg_custom_as_batch_size’ ); function tg_custom_as_batch_size( $batch_size ) { return 100; // Increases items processed per batch from 100 to 150 } to help speed things up but even if its not on the stuff piles up as much as 2 days (if not more) its mostly gla jobs also got this in my functions add_filter( ‘action_scheduler_retention_period’, ‘t*****custom_as_retention’ ); function t****_custom_as_retention( $period ) { return 3 * DAY_IN_SECONDS; } i asterixed it out her but this to clear old logs etc I had to go to terminal in cpanel and run php wp-cli.phar action-scheduler run –batches=5 –force (i change the 5 to 50 or 100 depending on the servers performance) everything is updated on teh site my sql database starts eating RAM when this piles up. (Slowly) *sql tables are about 7million i have a ton of stuff now originally had the advanced scheduler as recommened by one of your teams but seems to do nothing to help (so i purged it google gemini advised it can cause issues cause it starts looping). and trust me optimised SQL to death. Since i got past due up to date to 186 at 2am and now being 08:30 am its on 2552 and pending is on 3456 I find no suspiciouos bots attacking the site etc again its mostly gla/jobs/update_products/process_item (in past due its 1352) and woocommerce_run_product_attribute_lookup_update_callback (in past due its 1153) Yes stock updates every few hours this issue cuase that stock updates to slow down to a point it takes close to an hour to run the updated even on 3000 skus and its just QTY updates if i do regular_price manually its fine but i know if its via real cron takes about an hour when these things piles up. IF this helps (For security i changed the tables names to REDACTED NAME for here WordPress Environment<br><br>WordPress address (URL): https://www.techguysa.co.za<br>Site address (URL): https://www.techguysa.co.za<br>WC Version: 10.8.1<br>Legacy REST API Package Version: ✔ 1.0.5<br>Action Scheduler Version: ✔ 3.9.3<br>Log Directory Writable: ✔<br>WP Version: 7.0<br>WP Multisite: –<br>WP Memory Limit: 4 GB<br>WP Debug Mode: –<br>WP Cron: –<br>WP Environment Type: production<br>Language: en_US<br>External object cache: ✔ Server Environment<br><br>Server Info: LiteSpeed<br>Server Architecture: Linux 5.14.0-611.16.1.el9_7.x86_64 x86_64<br>PHP Version: 8.3.31<br>PHP Post Max Size: 512 MB<br>PHP Time Limit: 2400<br>PHP Max Input Vars: 100000<br>cURL Version: 8.19.0<br>OpenSSL/3.5.1<br><br>SUHOSIN Installed: –<br>MySQL Version: 11.4.12-MariaDB<br>Max Upload Size: 512 MB<br>Default Timezone is UTC: ✔<br>fsockopen/cURL: ✔<br>SoapClient: ✔<br>DOMDocument: ✔<br>GZip: ✔<br>Multibyte String: ✔<br>Remote Post: ✔<br>Remote Get: ✔ Database<br><br>WC Database Version: 10.8.1<br>WC Database Prefix: Redacted NAME_<br>Total Database Size: 1978.31MB<br>Database Data Size: 994.19MB<br>Database Index Size: 984.12MB<br>Redacted NAME_woocommerce_sessions: Data: 1.52MB + Index: 2.11MB + Engine InnoDB<br>Redacted NAME_woocommerce_api_keys: Data: 0.02MB + Index: 0.03MB + Engine InnoDB<br>Redacted NAME_woocommerce_attribute_taxonomies: Data: 0.02MB + Index: 0.02MB + Engine InnoDB<br>Redacted NAME_woocommerce_downloadable_product_permissions: Data: 0.02MB + Index: 0.08MB + Engine InnoDB<br>Redacted NAME_woocommerce_order_items: Data: 2.52MB + Index: 1.52MB + Engine InnoDB<br>Redacted NAME_woocommerce_order_itemmeta: Data: 26.58MB + Index: 32.67MB + Engine InnoDB<br>Redacted NAME_woocommerce_tax_rates: Data: 0.02MB + Index: 0.06MB + Engine InnoDB<br>Redacted NAME_woocommerce_tax_rate_locations: Data: 0.02MB + Index: 0.05MB + Engine InnoDB<br>Redacted NAME_woocommerce_shipping_zones: Data: 0.02MB + Index: 0.02MB + Engine InnoDB<br>Redacted NAME_woocommerce_shipping_zone_locations: Data: 0.23MB + Index: 0.33MB + Engine InnoDB<br>Redacted NAME_woocommerce_shipping_zone_methods: Data: 0.02MB + Index: 0.03MB + Engine InnoDB<br>Redacted NAME_woocommerce_payment_tokens: Data: 0.02MB + Index: 0.02MB + Engine InnoDB<br>Redacted NAME_woocommerce_payment_tokenmeta: Data: 0.02MB + Index: 0.03MB + Engine InnoDB<br>Redacted NAME_woocommerce_log: Data: 0.02MB + Index: 0.02MB + Engine InnoDB<br>Redacted NAME_actionscheduler_actions: Data: 6.25MB + Index: 20.69MB + Engine InnoDB<br>Redacted NAME_actionscheduler_claims: Data: 0.02MB + Index: 0.02MB + Engine InnoDB<br>Redacted NAME_actionscheduler_groups: Data: 0.02MB + Index: 0.02MB + Engine InnoDB<br>Redacted NAME_actionscheduler_logs: Data: 3.52MB + Index: 3.03MB + Engine InnoDB<br>Redacted NAME_clarity_collect_events: Data: 0.09MB + Index: 0.00MB + Engine InnoDB<br>Redacted NAME_commentmeta: Data: 0.33MB + Index: 0.69MB + Engine InnoDB<br>Redacted NAME_comments: Data: 32.56MB + Index: 44.70MB + Engine InnoDB<br>Redacted NAME_frm_fields: Data: 0.13MB + Index: 0.05MB + Engine InnoDB<br>Redacted NAME_frm_forms: Data: 0.02MB + Index: 0.02MB + Engine InnoDB<br>Redacted NAME_frm_items: Data: 0.47MB + Index: 0.34MB + Engine InnoDB<br>Redacted NAME_frm_item_metas: Data: 1.52MB + Index: 0.72MB + Engine InnoDB<br>Redacted NAME_gla_attribute_mapping_rules: Data: 0.02MB + Index: 0.00MB + Engine InnoDB<br>Redacted NAME_gla_budget_recommendations: Data: 0.19MB + Index: 0.11MB + Engine InnoDB<br>Redacted NAME_gla_merchant_issues: Data: 4.52MB + Index: 0.00MB + Engine InnoDB<br>Redacted NAME_gla_merchant_price_benchmarks: Data: 0.16MB + Index: 0.09MB + Engine InnoDB<br>Redacted NAME_gla_shipping_rates: Data: 0.02MB + Index: 0.05MB + Engine InnoDB<br>Redacted NAME_gla_shipping_times: Data: 0.02MB + Index: 0.02MB + Engine InnoDB<br>Redacted NAME_ht_activity: Data: 0.06MB + Index: 0.02MB + Engine InnoDB<br>Redacted NAME_ht_ip_list: Data: 0.38MB + Index: 0.11MB + Engine InnoDB<br>Redacted NAME_indexnow_failed_submissions: Data: 0.02MB + Index: 0.00MB + Engine InnoDB<br>Redacted NAME_indexnow_passed_submissions: Data: 0.28MB + Index: 0.00MB + Engine InnoDB<br>Redacted NAME_links: Data: 0.02MB + Index: 0.02MB + Engine InnoDB<br>Redacted NAME_litespeed_avatar: Data: 0.02MB + Index: 0.03MB + Engine InnoDB<br>Redacted NAME_litespeed_crawler: Data: 6.52MB + Index: 6.06MB + Engine InnoDB<br>Redacted NAME_litespeed_crawler_blacklist: Data: 1.52MB + Index: 0.59MB + Engine InnoDB<br>Redacted NAME_litespeed_url: Data: 0.34MB + Index: 0.50MB + Engine InnoDB<br>Redacted NAME_litespeed_url_file: Data: 1.52MB + Index: 1.67MB + Engine InnoDB<br>Redacted NAME_nm_personalized: Data: 0.02MB + Index: 0.00MB + Engine InnoDB<br>Redacted NAME_options: Data: 6.50MB + Index: 0.39MB + Engine InnoDB<br>Redacted NAME_parcelpanel_courier: Data: 0.02MB + Index: 0.00MB + Engine InnoDB<br>Redacted NAME_parcelpanel_location: Data: 0.02MB + Index: 0.00MB + Engine InnoDB<br>Redacted NAME_parcelpanel_tracking: Data: 0.02MB + Index: 0.05MB + Engine InnoDB<br>Redacted NAME_parcelpanel_tracking_items: Data: 0.02MB + Index: 0.03MB + Engine InnoDB<br>Redacted NAME_postmeta: Data: 334.98MB + Index: 427.84MB + Engine InnoDB<br>Redacted NAME_posts: Data: 137.59MB + Index: 25.09MB + Engine InnoDB<br>Redacted NAME_relevanssi: Data: 153.84MB + Index: 173.95MB + Engine InnoDB<br>Redacted NAME_relevanssi_log: Data: 0.02MB + Index: 0.03MB + Engine InnoDB<br>Redacted NAME_relevanssi_stopwords: Data: 0.02MB + Index: 0.00MB + Engine InnoDB<br>Redacted NAME_revslider_css: Data: 0.13MB + Index: 0.02MB + Engine InnoDB<br>Redacted NAME_revslider_css_bkp: Data: 0.02MB + Index: 0.00MB + Engine InnoDB<br>Redacted NAME_revslider_layer_animations: Data: 0.02MB + Index: 0.00MB + Engine InnoDB<br>Redacted NAME_revslider_layer_animations_bkp: Data: 0.02MB + Index: 0.00MB + Engine InnoDB<br>Redacted NAME_revslider_navigations: Data: 0.02MB + Index: 0.00MB + Engine InnoDB<br>Redacted NAME_revslider_navigations_bkp: Data: 0.02MB + Index: 0.00MB + Engine InnoDB<br>Redacted NAME_revslider_sliders: Data: 2.52MB + Index: 0.02MB + Engine InnoDB<br>Redacted NAME_revslider_sliders7: Data: 0.22MB + Index: 0.02MB + Engine InnoDB<br>Redacted NAME_revslider_sliders_bkp: Data: 1.52MB + Index: 0.00MB + Engine InnoDB<br>Redacted NAME_revslider_slides: Data: 1.52MB + Index: 0.02MB + Engine InnoDB<br>Redacted NAME_revslider_slides7: Data: 1.52MB + Index: 0.02MB + Engine InnoDB<br>Redacted NAME_revslider_slides_bkp: Data: 1.52MB + Index: 0.00MB + Engine InnoDB<br>Redacted NAME_revslider_static_slides: Data: 0.02MB + Index: 0.02MB + Engine InnoDB<br>Redacted NAME_revslider_static_slides_bkp: Data: 0.02MB + Index: 0.00MB + Engine InnoDB<br>Redacted NAME_sa_captured_wc_fields: Data: 0.02MB + Index: 0.00MB + Engine InnoDB<br>Redacted NAME_sfa_abandoned_carts: Data: 17.52MB + Index: 0.00MB + Engine InnoDB<br>Redacted NAME_smsalert_booking_reminder: Data: 0.02MB + Index: 0.00MB + Engine InnoDB<br>Redacted NAME_smsalert_renewal_reminders: Data: 0.02MB + Index: 0.00MB + Engine InnoDB<br>Redacted NAME_termmeta: Data: 22.61MB + Index: 51.73MB + Engine InnoDB<br>Redacted NAME_terms: Data: 8.52MB + Index: 7.03MB + Engine InnoDB<br>Redacted NAME_term_relationships: Data: 21.55MB + Index: 23.03MB + Engine InnoDB<br>Redacted NAME_term_taxonomy: Data: 9.52MB + Index: 8.03MB + Engine InnoDB<br>Redacted NAME_usermeta: Data: 31.58MB + Index: 40.67MB + Engine InnoDB<br>Redacted NAME_users: Data: 2.52MB + Index: 0.97MB + Engine InnoDB<br>Redacted NAME_vi_woo_orders_tracking_track_info: Data: 0.02MB + Index: 0.00MB + Engine InnoDB<br>Redacted NAME_wcpdf_invoice_number: Data: 0.02MB + Index: 0.00MB + Engine InnoDB<br>Redacted NAME_wc_admin_notes: Data: 0.16MB + Index: 0.00MB + Engine InnoDB<br>Redacted NAME_wc_admin_note_actions: Data: 0.09MB + Index: 0.02MB + Engine InnoDB<br>Redacted NAME_wc_category_lookup: Data: 0.13MB + Index: 0.00MB + Engine InnoDB<br>Redacted NAME_wc_customer_lookup: Data: 1.52MB + Index: 0.64MB + Engine InnoDB<br>Redacted NAME_wc_download_log: Data: 0.02MB + Index: 0.03MB + Engine InnoDB<br>Redacted NAME_wc_orders: Data: 3.52MB + Index: 1.72MB + Engine InnoDB<br>Redacted NAME_wc_orders_meta: Data: 18.58MB + Index: 22.11MB + Engine InnoDB<br>Redacted NAME_wc_order_addresses: Data: 2.52MB + Index: 1.63MB + Engine InnoDB<br>Redacted NAME_wc_order_coupon_lookup: Data: 0.02MB + Index: 0.03MB + Engine InnoDB<br>Redacted NAME_wc_order_operational_data: Data: 1.52MB + Index: 0.48MB + Engine InnoDB<br>Redacted NAME_wc_order_product_lookup: Data: 1.52MB + Index: 1.61MB + Engine InnoDB<br>Redacted NAME_wc_order_stats: Data: 1.52MB + Index: 0.88MB + Engine InnoDB<br>Redacted NAME_wc_order_tax_lookup: Data: 0.48MB + Index: 0.38MB + Engine InnoDB<br>Redacted NAME_wc_product_attributes_lookup: Data: 3.52MB + Index: 5.03MB + Engine InnoDB<br>Redacted NAME_wc_product_download_directories: Data: 0.02MB + Index: 0.02MB + Engine InnoDB<br>Redacted NAME_wc_product_meta_lookup: Data: 9.52MB + Index: 17.13MB + Engine InnoDB<br>Redacted NAME_wc_rate_limits: Data: 0.02MB + Index: 0.02MB + Engine InnoDB<br>Redacted NAME_wc_reserved_stock: Data: 0.02MB + Index: 0.02MB + Engine InnoDB<br>Redacted NAME_wc_tax_rate_classes: Data: 0.02MB + Index: 0.02MB + Engine InnoDB<br>Redacted NAME_wc_webhooks: Data: 0.34MB + Index: 0.11MB + Engine InnoDB<br>Redacted NAME_wfauditevents: Data: 0.02MB + Index: 0.00MB + Engine InnoDB<br>Redacted NAME_wfblockediplog: Data: 0.02MB + Index: 0.00MB + Engine InnoDB<br>Redacted NAME_wfblocks7: Data: 0.02MB + Index: 0.05MB + Engine InnoDB<br>Redacted NAME_wfconfig: Data: 1.52MB + Index: 0.00MB + Engine InnoDB<br>Redacted NAME_wfcrawlers: Data: 0.05MB + Index: 0.00MB + Engine InnoDB<br>Redacted NAME_wffilech...
Hey there, Thanks for sharing all that detail, the environment info, the server specs, and the code snippets. That makes it much easier to pinpoint what is happening here. The root cause: WP-Cron is disabled From the environment details you shared in your post, we can see that WP Cron is disabled on your site. This is a critical detail because Action Scheduler relies on WP-Cron to automatically trigger its queue runner every minute. With WP-Cron disabled and no server-side cron replacement firing wp-cron.php on a schedule, Action Scheduler has no way to automatically process the queue. That explains why actions pile up so fast overnight and between your manual WP-CLI runs. The fix: automate your WP-CLI command via a cPanel cron job You are already doing exactly the right thing by running wp action-scheduler run through your cPanel terminal. The issue is that you are doing it manually. Since you have cPanel access, you can automate this by setting up a cron job through cPanel’s Cron Jobs interface to run that same command every minute or every two minutes. This way, the queue will be continuously drained without you having to intervene. You can use the --batch-size and --batches flags to control how much work each run does, and the --group flag to prioritize specific action groups if needed. The full set of options is documented on the Action Scheduler WP-CLI page . For background on why WP-CLI processing is the recommended approach for high-volume stores like yours, take a look at the Action Scheduler Background Processing at Scale guide . Additionally, even with WP-Cron disabled, it is good practice to still have a server-side cron job triggering wp-cron.php so that other WordPress scheduled events continue to work normally. The WooCommerce guide on replacing WP-Cron with a real cron job walks through how to set that up in cPanel. A quick note on your code snippets The comments in your concurrent batches filter say “Bumps from 2 to 4” while the function returns 2. Similarly, the batch size comment says “Increases from 100 to 150” while it returns 100. The actual values sent to Action Scheduler are whatever the function returns, so the comments and the code are out of sync. That said, once you have a cron-driven WP-CLI runner in place, these web-based queue tuning filters become much less important since WP-CLI bypasses those limits entirely when using the --force flag. With 60,000+ products and Google for WooCommerce syncing each one individually through Action Scheduler, a cron-automated WP-CLI setup is really the way to go for a store at your scale. It will keep the queue moving around the clock without relying on site traffic or manual intervention.
HI yes cron disabled for real cron in wp-config define( ‘DISABLE_WP_CRON’, true ); This is in $table_prefix =DATABASE NAME and in cpanel cron jobs to run every 5 mins cd /home/foldername/public_html && /usr/local/bin/php wp-cron.php >/dev/null 2>&1 now after i made this post i did add this in cron jobs in cpanel which works set for every 1 min cd /home/folder name goes here/public_html && /usr/local/bin/php wp-cli.phar action-scheduler run >/dev/null 2>&1 i did have the batch sizes changed before all that with 2 ques and batch of 100 then 150 (no real change on resources) the reason for the 2 is cause 8 cores on the server but its got 2 light speed workers. i have had to use this in terminal to clear majority of it after CD in its php wp-cli.phar action-scheduler run –batches=10 –force the 10 was cause last time i used it was about 2000 jobs behind after that i implemented the cron for every 1 min its been behaving since i normally see it at 900 with only 180 past due which is weird cause those 180 are future jobs (i.e sales falls away after x date)
Thanks for the follow-up and for sharing the details of your cron configuration. It sounds like things are in much better shape now. To clarify, your original server cron running wp-cron.php every 5 minutes was already handling standard WordPress scheduled events correctly. The piece that was missing was a dedicated cron for Action Scheduler’s WP-CLI queue runner, and adding that at a one minute interval is the right approach for a store of your size. With 60,000+ products and Google for WooCommerce syncing each one through the queue, having a WP-CLI runner continuously draining actions is exactly how high volume stores are meant to operate. The Action Scheduler guide on Background Processing at Scale goes into more detail on why WP-CLI is the recommended approach once a store outgrows the default WP-Cron runner. About the ~180 past due actions you mentioned, that count is completely normal. Some of those are actions that become due between cron runs, since there is always a small window between each execution. Others, as you noted, are tied to scheduled WooCommerce events like sale end dates that have not reached their trigger time yet. The Action Scheduler FAQ confirms that having some past due actions is expected behavior. A count of 180 on a store with your volume is healthy. One thing worth keeping in mind for ongoing maintenance is the wp action-scheduler clean command. Running it periodically will prune old completed and cancelled actions from the database, keeping the actionscheduler_actions table lean over time. That should help with the database size and RAM concerns you mentioned earlier. The full set of options for the clean command is documented on the Action Scheduler WP-CLI page . We are glad we could help get this sorted out. If you have a moment, we would really appreciate it if you could leave a review on the Action Scheduler reviews page .
its just weird that it couldnt keep up with everything seems via wordpress there are some restrictions but the method i got now seems to be better servers ram is holding steady as well without it would hang / freeze and ram would build up close to OOM if not OOM on MariaDB (cause everything is waiting in que) unless im pushing the limits here