Home › Forums › WoodMart support forum › 503 errors and MySQL “Commands out of sync”

503 errors and MySQL “Commands out of sync”

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • February 26, 2026 at 3:02 am #709952

    jesusalvarado90
    Participant

    Hi,

    I am experiencing a critical issue on our production website after a recent WooCommerce update.

    Initially, the backend became extremely slow and we started receiving intermittent 503 and 524 errors. After extensive debugging, I traced the issue down to WooCommerce’s internal Batch Processing system.

    Even after cleaning sessions and optimizing the database, the problem persists. The error log is constantly filled with the following MySQL error:

    WordPress database error Commands out of sync; you can’t run this command now
    for query:

    SELECT option_value FROM wp_options
    WHERE option_name = ‘wc_pending_batch_processes’ LIMIT 1

    made by shutdown_action_hook,
    Automattic\WooCommerce\Internal\BatchProcessing\BatchProcessingController->remove_or_retry_failed_processors()

    The same error also appears for these related queries:

    SELECT p.ID FROM wp_posts
    WHERE post_type=’scheduled-action’
    AND post_title=’wc_schedule_pending_batch_processes’

    and

    SELECT a.action_id FROM wp_actionscheduler_actions
    WHERE hook=’wc_schedule_pending_batch_processes’

    This happens during the shutdown_action_hook, meaning WooCommerce’s BatchProcessingController is executing in shutdown and leaving the MySQL connection in an inconsistent state, resulting in:

    Commands out of sync; you can’t run this command now

    Important notes:

    Database tables are not corrupted.

    woocommerce_sessions was previously 5.7GB due to session accumulation, but has now been cleaned and optimized.

    wp_options was optimized and reduced from several GB to normal size.

    Action Scheduler tables were cleaned.

    WP-Cron is enabled.

    The issue still occurs even after disabling Action Scheduler default runner.

    The error continues unless the WooCommerce BatchProcessing module is disabled.

    Disabling the Woodmart Core plugin previously reduced server load significantly, but after deeper investigation the root cause appears related to WooCommerce BatchProcessing, not Woodmart itself.

    When this error starts occurring:

    CPU usage spikes to 100%

    RAM spikes

    The frontend eventually returns 503 errors

    The error log grows rapidly

    This only started after the recent WooCommerce update.

    Could you please confirm:

    Whether there is a known issue with BatchProcessingController and MariaDB 11?

    If wc_pending_batch_processes can become stuck or re-trigger infinitely?

    If there is a safe way to completely disable or reset WooCommerce Batch Processing without modifying core files?

    This is a production site, and the issue is recurring even after database cleanup.

    Thank you for your assistance.

    Kind regards.

    February 26, 2026 at 10:31 am #709995

    Artem Temos
    Keymaster
    Xtemos team

    Hi,

    Thank you for the detailed report. The errors you shared come from WooCommerce’s internal Batch Processing and Action Scheduler running on shutdown. This is WooCommerce core functionality and isn’t controlled by the WoodMart theme or WoodMart Core.

    We don’t have any reports of this issue with our theme, and no known incompatibilities with MariaDB 11 on our side. To fully isolate, please switch to the Storefront theme and keep only WooCommerce active. If the “Commands out of sync” errors still occur in that state, it confirms the issue is within WooCommerce and you should contact WooCommerce support so they can investigate BatchProcessingController and the related hooks/options.

    Kind Regards

    February 26, 2026 at 11:01 pm #710090

    jesusalvarado90
    Participant

    Hi,

    Thank you for your response.

    After deeper server-side analysis, we are seeing behavior that goes beyond standard WooCommerce core processing.

    During load spikes, the majority of active PHP processes (lsphp) are tied to frontend requests involving:

    WooCommerce product searches (?s=…&post_type=product)

    AJAX calls (admin-ajax.php, wc-ajax=get_refreshed_fragments)

    WoodMart filtering and layered navigation

    Dynamic product queries generated by the theme

    On the server we observed:

    PHP processes multiplying rapidly under concurrent frontend activity

    MySQL Threads_connected increasing significantly (70+)

    High CPU usage triggered primarily by frontend product filtering and dynamic catalog rendering

    Severe load spikes when cache is purged, indicating heavy dynamic generation

    While WooCommerce Action Scheduler does run background tasks, the actual CPU pressure is coming from frontend catalog queries and filtering logic, which are heavily influenced by the theme’s product filtering system and dynamic AJAX refresh mechanisms.

    Specifically:

    WoodMart’s layered filters generate complex WP_Query + meta_query + tax_query combinations.

    Product filtering appears to bypass effective full-page caching.

    Cart fragments and AJAX interactions significantly increase concurrent PHP execution.

    When cache is cold, WoodMart generates large numbers of simultaneous dynamic requests.

    To isolate further, we need confirmation on:

    Whether WoodMart performs additional product meta queries beyond standard WooCommerce filtering.

    Whether the theme triggers extra AJAX refresh cycles for mini cart, filters, or quick view.

    If there are recommended performance settings specific to WoodMart for high-concurrency WooCommerce environments.

    Whether there are known performance optimizations required when running under LiteSpeed + MariaDB 11.

    The issue is reproducible under frontend load conditions and correlates directly with dynamic filtering and catalog rendering behavior.

    We are not seeing evidence that the root cause is WooCommerce batch processing alone. The pressure is clearly coming from concurrent frontend PHP execution related to product filtering and dynamic rendering.

    We would appreciate guidance specifically related to WoodMart’s filtering system and AJAX handling under load.

    Kind regards,

    February 27, 2026 at 10:43 am #710133

    Artem Temos
    Keymaster
    Xtemos team

    Hi,

    Thanks for the detailed follow-up. A few clarifications and next steps specific to WoodMart:

    – WoodMart product filters are wrappers around WooCommerce’s native Layered Nav and price filter widgets. The actual product queries (tax_query/meta_query) are generated by WooCommerce, not the theme. Cart fragments and wc-ajax endpoints are also WooCommerce core.
    – There are no known WoodMart-specific incompatibilities with MariaDB 11 or WooCommerce’s BatchProcessing. The BatchProcessingController and wc_pending_batch_processes are part of WooCommerce core, so please continue with WooCommerce support on those shutdown/crud issues.

    What to test to isolate front-end load:
    1) Baseline with Storefront
    – Switch to Storefront and keep only WooCommerce active.
    – Add the same WooCommerce Layered Nav/Price widgets to the shop sidebar and repeat your load test. If the same endpoints spike and DB load persists, it confirms the bottleneck is in WooCommerce queries or traffic patterns, not WoodMart.

    2) AJAX shop toggle
    – In Theme Settings > Product archive, disable the AJAX shop and retest. This helps verify that asynchronous updates themselves aren’t the trigger.

    3) Out-of-stock sorting
    – If you use the “Out of stock products at the end” option (Theme Settings > Product archive), turn it off and retest. This feature modifies the main product query at runtime and can add overhead.

    4) Traffic/bot spikes
    – We’ve seen similar CPU spikes caused by aggressive bot/DoS traffic hitting catalog/search. If you observe threads/processes multiplying mainly under high-concurrency or immediately after cache purge, add firewall/CDN rules to block abusive IPs/ASNs/countries and rate-limit search and AJAX endpoints. If there is a DoS pattern, it must be mitigated first; no theme can handle that load alone.

    Kind Regards

  • Author
    Posts
Viewing 4 posts - 1 through 4 (of 4 total)