[wp-trac] [WordPress Trac] #29221: new wp_maybe_auto_update behavior can cause problems with large number of installs

[WordPress Trac]

#29221: new wp_maybe_auto_update behavior can cause problems with large number of
installs
-----------------------------+------------------------------
 Reporter:  growlingoctopus  |       Owner:
     Type:  defect (bug)     |      Status:  new
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  Upgrade/Install  |     Version:  3.9.2
 Severity:  normal           |  Resolution:
 Keywords:                   |     Focuses:
-----------------------------+------------------------------
Changes (by SergeyBiryukov):

 * component:  General => Upgrade/Install


Old description:

> The changes introduced in https://core.trac.wordpress.org/changeset/25825
> can create issues on large servers, such as shared hosting servers.
> There are actually 2 different bugs here:
>
> 1) According to the code this should set the cron to the 7:00 hour (am
> and pm) server time.  It doesn't usually do that, because this time is
> generated with strtotime('today 7am'), and in wp-settings.php the
> timezone is manually changed to UTC.  In most installs, the gmt offset is
> 0 and the timezone_string is blank, so these don't get properly applied
> either.  EG, on servers in central time, the updates really run during
> peak hours at 2 PM.
>
> 2) On servers with large numbers of installs, this can cause major
> issues.  There's the upgrader_scheduled_cleanup which calls
> wp_delete_attachment() for the upgrade files to clean up.  This searches
> things like comment tables for comments attached to the 'attachment'
> (even though there usually aren't any for this particular one, or are
> there ever?)  Since these are scheduled for exactly 2 hours after the
> upgrade, all of these will run during the same hour as well, which can
> cause extremely high I/O as all of these tables for many different
> databases are read through.
>

> The easiest way to fix the base problem for this would be to go back to a
> fully random time for these updates.  Another option is to have a
> blackout config option added, or have a static blackout window during the
> day.  The problem with these though is they would make it hard to do the
> twicedaily setup. Also, the timezone issue should probably be corrected
> if the code is kept in its current state, or it will run at unintended
> times.

New description:

 The changes introduced in [25825] can create issues on large servers, such
 as shared hosting servers.  There are actually 2 different bugs here:

 1) According to the code this should set the cron to the 7:00 hour (am and
 pm) server time.  It doesn't usually do that, because this time is
 generated with strtotime('today 7am'), and in wp-settings.php the timezone
 is manually changed to UTC.  In most installs, the gmt offset is 0 and the
 timezone_string is blank, so these don't get properly applied either.  EG,
 on servers in central time, the updates really run during peak hours at 2
 PM.

 2) On servers with large numbers of installs, this can cause major issues.
 There's the upgrader_scheduled_cleanup which calls wp_delete_attachment()
 for the upgrade files to clean up.  This searches things like comment
 tables for comments attached to the 'attachment' (even though there
 usually aren't any for this particular one, or are there ever?)  Since
 these are scheduled for exactly 2 hours after the upgrade, all of these
 will run during the same hour as well, which can cause extremely high I/O
 as all of these tables for many different databases are read through.


 The easiest way to fix the base problem for this would be to go back to a
 fully random time for these updates.  Another option is to have a blackout
 config option added, or have a static blackout window during the day.  The
 problem with these though is they would make it hard to do the twicedaily
 setup. Also, the timezone issue should probably be corrected if the code
 is kept in its current state, or it will run at unintended times.

--

--
Ticket URL: <https://core.trac.wordpress.org/ticket/29221#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform