[wp-trac] [WordPress Trac] #6897: Magpie cache persisting after deprecation (was: Magpie cache needs looking at)

[WordPress Trac]

#6897: Magpie cache persisting after deprecation
-------------------------------------------------+--------------------------
 Reporter:  Otto42                               |        Owner:  anonymous
     Type:  defect (bug)                         |       Status:  reopened 
 Priority:  normal                               |    Milestone:           
Component:  Cache                                |      Version:  3.0.1    
 Severity:  blocker                              |   Resolution:           
 Keywords:  Magpie, SimplePie, wp_options bloat  |  
-------------------------------------------------+--------------------------
Changes (by gazouteast):

  * status:  closed => reopened
  * severity:  normal => blocker
  * type:  enhancement => defect (bug)
  * component:  Optimization => Cache
  * version:  2.7 => 3.0.1
  * resolution:  wontfix =>


Comment:

 @ Denis - I don't care if it is deprecated or not, the problem is
 persistent across all my blogs, whether first built using WP 2.3 all the
 way through to brand new clean 3.0.1 builds that have NEVER had any
 plugins, and NO theme except twentyten.

 There is something still within WP that is causing this issue - it is
 neither resolved nor invalid.

 I lost another site yesterday due to this - one with 2000 posts in it -
 and the hosts want money to restore the database backup.  In this instance
 the wp_options table crashed with 77 MB of data and 145,000 rows in it.

 I lost an entire hosting account two weeks ago with 8 domains in it, and
 those hosts also want money to send me the backups.  My other domains on
 several hosts are also under threat due to this issue.

 (Side topic - it is only US hosts that are blackmailing and profiteering
 enough to demand payment for restoring backups in a crisis - UK and Asian
 hosts (that I use) do not do that - it's very much a GRRRR point for me -
 but something to think about asking hosting companies before adding them
 to the WP hosting directory).

 @dd32 - I haven't verified my sites have that code (please say where it
 should be) but I can absolutely guarantee it is not triggering, plus it is
 only half the issue - what about the entries with transient_ as the
 prefix?  Those are not addressed by that code, and they make up around
 35-40% of the entries.

 If any of the devs want unrestricted access to all my sites on all hosts,
 contact me - I'll gladly give it in order to get this resolved (for
 everyone, not just me).  If you'd prefer I send you a database dump - same
 applies.

 I guarantee this is not fixed - there is something somewhere in all 2.9.x
 and 3.x versions that is perpetuating the MagPie bloat, and/or causing it
 to not be removed.

 Also, I have noticed in server error logs, that wp_cron triggered events
 that include "scheduled_delete" related to the admin dashboard rss widgets
 (in particular "akismet_scheduled_delete\" and "wp_scheduled_delete\"),
 are causing database timeouts and "gone away" errors, therefore the
 scheduled deletes are not occurring.  wp_unschedule_event also commonly
 appears in those errors.

 Again, this is happening on all blogs on all hosts - far more on some than
 on others.

 Regarding the accelerating rate of "SQL Server Gone Away" I am seeing on
 some domains, I have some suspicions mod_fcgid max_processes and
 max_process_duration limits (on shared hosting) may be contributory where
 wp_cron has many items to include in a triggered run.  I am building up a
 new VPS today where I have full control of that, and am migrating some
 sites in the process to intrinsically test that theory - the sole purpose
 of the new VPS account - therefore I expect to have more data about it
 later this week.

 Pseudo crons such as wp_cron have regularly been cited as server stress
 points (it happened with many different forum scripts too) because they
 rely on visitor traffic to trigger - on quiet sites (e.g. tightly geo-
 focussed sites during night-time quiet patches), this causes a task
 accumulation which then swamps resources when a visitor lands.  Genuine
 crons to not cause this issue as they trigger according to the set period,
 regardless of traffic levels.  I hope to do some experimenting on this
 (moving wp_cron to genuine cron) a little later in the year - I need to
 build a site for hacking-core first though.

 Gaz

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/6897#comment:10>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software