• Resolved alduinwf

    (@alduinwf)


    Hi,

    thank you for your effort on this plugin ??

    However, I noticed that the update (via plugin auto update) killed most of the sites of mine and caused massive database load on the servers.

    As far as I saw it, the problem is the following:

    When the plugin notices that the current data is old (from an old version), it’ll update the data. It however does this on every request. So that means if you have a fairly busy website and quite some articles to process, chances are that multiple instances of the updater are running at the same time.

    This causes massive loads and eventually outages (too many connections for example). And it puts the data multiple times into postmeta because job #2 doesn’t know about job #1 already running (though not yet quite finished.

    My proposal would be that you put a lock into wp_options that an update job is already running which you remove upon completion.

    This also gives you the flexibility of doing a staged migration, so that it would only do say 1000 posts at a time.

    I also noticed that a previous update missed to set the kksr_ver to 4.2 (despite me having 4.2 installed), so it runs v2 to v4 first and then (at the same request) v4 to v5 then. This could also be mitigated with a lock information. ??

    Thanks!

Viewing 7 replies - 1 through 7 (of 7 total)
  • Plugin Contributor Kamal Khan

    (@bhittani)

    Fair point. Thanks for the heads up! Will deal with this in the next update.

    • This reply was modified 3 years, 5 months ago by Kamal Khan.
    Thread Starter alduinwf

    (@alduinwf)

    Wonderful, thank you again for your work ??

    Thank you for your effort!
    It still has same issue with version 5.0.3, so I rolled back to 4.2 again.

    Thread Starter alduinwf

    (@alduinwf)

    My solution workaround was to block all IPs (except mine) with a

    allow from <my ip>
    deny from all

    in the htaccess, then restart the webserver (Apache in my case), try to access the site, have it upgrade, and when it was responsive again, remove those line from htaccess.

    If you use another webserver, you’d do this accordingly.

    That way, I sort of enforced the job only running once. It still invalidated almost all ratings, but at least I’m at 5.x now ??

    Maybe that helps you too.

    Plugin Contributor Kamal Khan

    (@bhittani)

    This has been introduced in 5.1.0 and fixes the problem.

    A concept of migrations has been introduced which migrates posts in batches in the background.

    Thread Starter alduinwf

    (@alduinwf)

    Thank you for that.

    However, I wonder:
    One of my sites went down, yet again. MySQL is doing all the load.

    1. Why would it migrate in the first place? Data was already KK 5.x

    2. It looks like it would for some reason start new jobs before the first job was finished. That would not help the issue…

    Plugin Contributor Kamal Khan

    (@bhittani)

    @alduinwf I dont think that new jobs would be started before a previous job is in process.

    Nevertheless, I have deprecated the use of migrations in 5.2.0 in favor of migrating posts only when accessed.

Viewing 7 replies - 1 through 7 (of 7 total)
  • The topic ‘Lock file for database update’ is closed to new replies.