[wp-trac] [WordPress Trac] #17210: Massive duplication of oEmbed postmeta

WordPress Trac wp-trac at lists.automattic.com
Mon Nov 7 01:50:58 UTC 2011


#17210: Massive duplication of oEmbed postmeta
--------------------------+---------------------------
 Reporter:  archon810     |       Owner:  Viper007Bond
     Type:  defect (bug)  |      Status:  reopened
 Priority:  normal        |   Milestone:
Component:  Embeds        |     Version:  3.1
 Severity:  normal        |  Resolution:
 Keywords:                |
--------------------------+---------------------------
Changes (by archon810):

 * status:  closed => reopened
 * resolution:  worksforme =>


Comment:

 I'd like to re-open this bug. I have a script that cleans out bad values
 from #17560 every day, which helps, but the problem still exists in WP
 3.2, and it's pretty bad. My server keeps getting annihilated after new
 posts, and I suspect it has something to do with these oembeds.

 For example, I just published a fresh post with a number of oembed tags.
 The load shot up to 50 and apache was maxing out big time. After it
 finally calmed down a few minutes later, I went to check and found this:

 {{{
 select distinct meta_key, count(*) as cnt from wp_postmeta where meta_key
 like '_oembed%' group by meta_key order by cnt desc limit 20;
 +------------------------------------------+-----+
 | meta_key                                 | cnt |
 +------------------------------------------+-----+
 | _oembed_0c83472a9e841c9ad60a38893f808eb6 | 176 |
 | _oembed_5acdb1907d1540ae412c8a8212f34826 | 176 |
 | _oembed_b8bf13bcc3898fd1a6d97946034aacfb | 176 |
 | _oembed_4d092cafea6ebaf8822f7c0598e1e527 | 175 |
 | _oembed_bd80b0ae6473d6273358e38813c91f21 | 175 |
 | _oembed_ccc6cfc349b836eed7ad88defad3812d | 175 |
 | _oembed_8a8284e37c86e4e1cc9bf9f4534a9230 | 175 |
 | _oembed_86c07331b01f79c929c56275e4a51696 | 175 |
 | _oembed_5f227997ee21e52a717dce2e815726f7 |  83 |
 | _oembed_4aa03f10ff8a01acdcea73fa8e934be9 |  81 |
 | _oembed_a9334d906665e64c06de2f811770dec3 |  80 |
 | _oembed_36b3fa71c7d97154385e622f6cb19945 |  76 |
 | _oembed_1ac243689d6da991beac8048902ae7aa |  73 |
 | _oembed_6e30160985bec33c2662edda70af41e2 |  71 |
 | _oembed_3422a41efb21a00716c6ac559afa43d4 |  64 |
 | _oembed_089232cc03ea36671c318afa1fe651c3 |  64 |
 | _oembed_ca71e42982bcf5bd136b25db37826695 |  63 |
 | _oembed_1673cbc900c2e6bb47469db2ff85a19b |  58 |
 | _oembed_c72a480c4f00f9e84e9ba59a346fd371 |  56 |
 | _oembed_0b9f5ab1f1e433dca163541ada9bf955 |  50 |
 +------------------------------------------+-----+
 }}}

 Checking one of those oembeds with 176 duplicates, I found that all 176
 are attached to the same post id, the one I just published. This points
 towards some sort of a concurrency issue - as if all PHP threads suddenly
 see a new oembed tag that hasn't been resolved yet and all try to do it at
 the same time. I'm not sure what the mechanism for that is, perhaps it's
 related to wp-cron concurrency issues, but perhaps not.

 It's also worth pointing out that I have apache configured with 170 max
 children, which is suspiciously close to 176.

 P.S. I've switched from WP Super Cache to W3 Total Cache (latest public
 version 0.9.2.4) to utilize memcached support, in case this ends up being
 important. I'm using page cache, object cache, and db cache, all pulling
 from memcached.

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


More information about the wp-trac mailing list