Question

因此，随着时间的流逝，我注意到我的网站越来越慢，通常是在高峰时段和周末-CPU负载将达到应有的10倍，并且网站通常会无响应。

经过大量修改之后，我发现注释掉这一行会使CPU负载降至正常：

$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));

这是来自WordPress插件的代码。下载文件时会触发，并且很容易解释，只需将hits / IP / date等记录到数据库中的相应行。

我不明白为什么这个非常简单的更新查询会导致这种情况？

一些信息：

在正常流量下，该网站可以很好地处理大约150个并发用户，其中大多数用户未登录，因此可以接收缓存的页面。
在大流量情况下〜300个并发用户，这是情况恶化的时候。但是即使在正常通信量下，CPU也会跳到“不良”范围。关键是，CPU的极端负载似乎是零星的，但在流量较大的情况下，绝对更加明显。
删除此查询-以便继续提供下载服务，并且除了要更新的数据库外，所有其他与下载相关的代码仍在执行-并且即使有约300个在线用户，CPU负载也将保持在“正常”至“正常”范围内。因此，此查询绝对是罪魁祸首，或者至少是最大的罪魁祸首。
有问题的数据库表包含约23,000行。如果有什么原因，我认为可能是文本搜索引起的，但是禁用用户的前端搜索并不能解决这种问题。

Answer 1

您的UPDATE查询似乎运行缓慢。那可能是因为

数据库中的表由于某种原因变得碎片化或混乱，或者
它需要file_id列上的索引，以便WHERE file_id = something可以在您的UPDATE中更快地运行。

这是WP-Filebase插件吗？如果是这样，则与插件作者联系的通常建议不适用，因为该插件已被wordpress.org当局关闭。

您正在备份，对吗？如果没有，请先备份数据库。

您需要自己修复慢速表。最好在您的网站流量少的时候执行此操作。

打开phpmyadmin，打开WordPress数据库，然后查找名称为wp_filebase_files或wp_filebasefiles之类的表。单击名称。（我不知道确切的表名是什么。）

然后单击屏幕顶部的“操作”标签。

然后，在“表维护”下，单击“优化表”链接。它可能会运行一段时间。然后查看性能是否提高。如果那没有帮助，请单击“修复表”链接。然后再次尝试性能。

如果这些方法没有帮助，则您可能需要在表上建立索引。这是添加一个的方法。

在phpMyAdmin的左侧，单击表旁边的[+]符号，然后单击“列和索引”旁边的[+]符号。

如果它显示file_id作为索引，则您已经拥有查询所需的索引，而我的建议对您无济于事。（抱歉）

如果没有，请单击“索引”下的“ 新建”。您将看到一个对话框。像这样填写。

索引名称：filebase_file_id
索引选择：从下拉菜单中选择“索引”。
列：从下拉列表中选择file_id。
大小：留空。

然后单击“执行”。创建索引可能需要一段时间。然后查看您的演奏是否加快。

这种事情发生在繁忙的数据库中；很正常，但是脖子很疼。

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

1 个答案: