为什么此UPDATE查询会杀死我的CPU？

Question

So over time I've noticed my website getting slower and slower, normally at peak traffic hours and weekends - the CPU load would hit 10x what it should be and often the website would turn unresponsive.

After much hacking away at stuff, I've discovered commenting out this line brings the CPU load down to normalcy:

$this->file_hits++;
$this->weekly_file_hits++;
$this->daily_file_hits++;
$this->file_last_dl_ip = $downloader_ip;
$this->file_last_dl_time = current_time('mysql');

$wpdb->query("UPDATE " . $wpdb->wpfilebase_files
    . " SET file_hits = file_hits + 1, weekly_file_hits = weekly_file_hits + 1, daily_file_hits = daily_file_hits + 1, file_last_dl_ip = '"
    . $downloader_ip . "', file_last_dl_time = '"
    . $this->file_last_dl_time . "' WHERE file_id = "
    . (0+$this->file_id));

This is code from a WordPress plugin. It fires when a file is downloaded, and is pretty self explanatory, just logs hits/IP/date etc into the appropriate row in the DB.

I don't understand why this pretty simple update query would result in this?

Some info:

1. The website handles well under normal traffic ~150 simultaneous users, most of whom are not logged in and thus receive cached pages.
2. Under large traffic ~300 simultaneous users, is when things get bad. But even at normal traffic CPU can jump around to "bad" ranges too. Point is, the extreme CPU load seems very sporadic but is definitely more pronounced with heavier traffic.
3. Removing this query - so downloads are still served and all the other download-related code is still executed besides the DB being updated - and CPU load stays at "good" to "normal" ranges even with ~300 users online. So this query is definitely the culprit, or is at least the biggest culprit.
4. The DB table in question contains something like 23,000 rows. If anything I'd think the text searching would have been the cause for this, but disabling users' front-end search didn't remedy anything like this did.

Answer 1

It looks like your UPDATE query is running slowly. That could be because

1. the table in your database has become fragmented or messed up somehow, or
2. it needs an index on the file_id column so WHERE file_id = something can run faster in your UPDATE .

Is this the WP-Filebase plugin? If so, the usual advice to contact the plugin author doesn't apply, because the plugin has been closed by the wordpress.org authorities.

You are doing backups, right? If not, back up your database before doing anything else.

You need to fix up the slow table yourself. It's best to do this at a low-traffic time for your site.

Open up phpmyadmin, open your WordPress database, and look for a table with a name like wp_filebase_files or wp_filebasefiles . Click on the name. (I don't know exactly what the table name is.)

Then click the Operations tab at the top of your screen.

Then, under Table maintenance click the Optimize Table link. It may run for a while. Then see if performance improves. If that doesn't help, click the Repair Table link. Then try performance again.

If these don't help, you may need an index on your table. Here's how to add one.

On the left side of phpMyAdmin, click the [+] sign next to your table, then click the [+] signs next to Columns and Indexes.

If it shows file_id as an index, you already have the index your query needs, and my advice can't help you. (Sorry.)

If it doesn't, click New under Indexes. You'll get a dialog box. Fill it out like this.

• Index name: filebase_file_id
• Index choice: choose "INDEX" from the dropdown menu.
• Column: from the dropdown, pick file_id.
• Size: leave it blank.

Then click Go. It may take a while to create the index. Then see if your performance picks up.

This kind of thing happens to busy databases; it's normal, but it's a pain in the neck.