Support » Plugin: Jetpack by » jpsq_full_sync: flooding database

  • Resolved design_dolphin


    This issue is possibly similar to:

    Jetpack Version
    4.9, latest update did not resolve issue in this instance

    jpsq_full_sync- fills database, which results in slowing down of the site possibly, especially when other plugins try to access the options table?
    Possibly also because of the way the host has it set up, that if it runs too much it will offload/ kill the process/ site, and restart (looking at logs this is possibly happening), Disabling Jetpack solves the problem, however, one still needs to go into phpMyAdmin for example to clean the left over rows.

    Steps Taken
    1. Tried running Jetpack in dev mode, did not make a difference
    2. The only modules on are contact form, Photon, and Shortcode Embeds
    3. Looking at: /wp-content/plugins/jetpack/sync/class.jetpack-sync-defaults.php

    Jetpack sync runs often, and when it does a lot, as a temporary solution increased the $default_sync_time, $default_sync_wait_time, $default_queue_max_writes_sec, but that didn’t work. So set $default_disable to 1, that appears to have worked, although not sure if that is the reason it ‘fixed’ it (Edit: that did not fix the issue). This is only a temporary bug fix, to aid in a solution, and core/ plugin should be not edited as such.

    A bit surprised by the amount of rows that can be created, and in the shortness of time, while there may be a valid reason, there may be a better safeguard need, different value, to stop a database from flooding. In the time it took to create this post it has created about 1200 rows.

    static $default_taxonomy_whitelist = array();
    	static $default_dequeue_max_bytes = 500000; // very conservative value, 1/2 MB
    	static $default_upload_max_bytes = 600000; // a little bigger than the upload limit to account for serialization
    	static $default_upload_max_rows = 500;
    	static $default_sync_wait_time = 100; // seconds, between syncs
    	static $default_sync_wait_threshold = 5; // only wait before next send if the current send took more than X seconds
    	static $default_enqueue_wait_time = 10; // wait between attempting to continue a full sync, via requests
    	static $default_max_queue_size = 1000;
    	static $default_max_queue_lag = 900; // 15 minutes
    	static $default_queue_max_writes_sec = 10; // 100 rows a second
    	static $default_post_types_blacklist = array();
    	static $default_post_meta_whitelist = array();
    	static $default_comment_meta_whitelist = array();
    	static $default_disable = 1; // completely disable sending data to wpcom
    	static $default_sync_via_cron = 1; // use cron to sync
    	static $default_render_filtered_content = 0; // render post_filtered_content
    	static $default_max_enqueue_full_sync = 100; // max number of items to enqueue at a time when running full sync
    	static $default_max_queue_size_full_sync = 1000; // max number of total items in the full sync queue
    	static $default_sync_callables_wait_time = MINUTE_IN_SECONDS; // seconds before sending callables again
    	static $default_sync_constants_wait_time = HOUR_IN_SECONDS; // seconds before sending constants again
    	static $default_sync_queue_lock_timeout = 120; // 2 minutes
    	static $default_cron_sync_time_limit = 30; // 30 seconds

    Possible Solution
    Check if the plugin is deleting the entries already made, and if it already has entries, don’t add new ones, until they are deleted, or send an error message/ email that there is a problem with the plugin.

Viewing 2 replies - 1 through 2 (of 2 total)
  • Plugin Author Jeremy Herve


    Jetpack Mechanic 🚀

    We have a few safeguards in place to monitor sync processes that may be stuck and to clean up sync transients, but apparently none of this appears to be working on your site.

    Would you mind contacting us via this contact form and mention this thread so we can take a look at your setup and understand what’s happening?


    The contact form has been sent.

Viewing 2 replies - 1 through 2 (of 2 total)
  • The topic ‘jpsq_full_sync: flooding database’ is closed to new replies.