之前就有遇過 WordPress 網站突然反應很慢 的問題，

那時在 atop 中看到 mysqld 的 CPU 使用率很高，

不過因為找不出原因，只是先調整了 Google Cloud Platform 上的機器等級，

把記憶體加大，讓它不會因為記憶體不足，跑去寫 SWAP 導致系統很慢…

 

但是那台機器上的 WordPress 仍然很常反應遲緩，

每次要連進網頁，都要好幾秒鐘的時間…

今天終於找出兇手啦～來看一下過程吧～

 

先來看一下 atop 的資訊，

發現 mysql.bin 的 CPU 使用率常常飆到 80~90% 以上，然後又降下來，

過個幾秒後，又開始上升下降，頻率相當的高：

 

上網查到一些資訊，有各種可能性，

像有人說 NTP 重啟可能有效，但我的機器顯然不是這問題。

有一個人提供的方式最有效，

那就是在 CPU 使用率高的時候，去看 MySQL 到底在執行什麼東西～

 

先登入 mysql：

mysql -u root -p

 

在 mysql 提示符號，執行 SHOW PROCESSLIST; 可以列出目前在執行的 MySQL 指令。

平常沒事大概都像下面這樣，一個 event_scheduler 在等工作，

一個就是 SHOW PROCESSLIST 自己：

mysql> SHOW PROCESSLIST;
+--------+-----------------+-----------+-------------------+---------+--------+------------------------+------------------+
| Id     | User            | Host      | db                | Command | Time   | State                  | Info             |
+--------+-----------------+-----------+-------------------+---------+--------+------------------------+------------------+
|      4 | event_scheduler | localhost | NULL              | Daemon  | 690074 | Waiting on empty queue | NULL             |
| 117270 | root            | localhost | bitnami_wordpress | Query   |      0 | starting               | SHOW PROCESSLIST |
+--------+-----------------+-----------+-------------------+---------+--------+------------------------+------------------+

 

但我在 CPU 使用率高的時候，連續去執行 SHOW PROCESSLIST，

就蠻常看到如下的資訊：

mysql> SHOW PROCESSLIST;
+--------+-----------------+-----------+-------------------+---------+--------+------------------------+--------------------------------------------------------------------------------------+
| Id     | User            | Host      | db                | Command | Time   | State                  | Info                                                                                 |
+--------+-----------------+-----------+-------------------+---------+--------+------------------------+--------------------------------------------------------------------------------------+
|      4 | event_scheduler | localhost | NULL              | Daemon  | 690244 | Waiting on empty queue | NULL                                                                                 |
| 117270 | root            | localhost | bitnami_wordpress | Query   |      0 | starting               | SHOW PROCESSLIST                                                                     |
| 117317 | bn_wordpress    | localhost | bitnami_wordpress | Query   |      1 | executing              | SELECT COUNT(*) FROM wp_vcp_log WHERE `Time` > DATE_SUB(NOW(), INTERVAL 5 HOUR)      |
| 117318 | bn_wordpress    | localhost | bitnami_wordpress | Query   |      1 | executing              | SELECT COUNT(*) FROM wp_vcp_log WHERE WEEKOFYEAR(`Time`)=WEEKOFYEAR(NOW())           |
| 117319 | bn_wordpress    | localhost | bitnami_wordpress | Query   |      0 | executing              | SELECT COUNT(*) FROM wp_vcp_log WHERE IP='118.232.12.42' AND DATE(Time)='2020-04-11' |
+--------+-----------------+-----------+-------------------+---------+--------+------------------------+--------------------------------------------------------------------------------------+

 

可以看到，有人在查詢 wp_vcp_log 這個資料表，

而且查法很多種，會查時間、會找 IP 等等，

一次就打了兩三個 SQL 敘述，而且非常頻繁。

 

這個 wp_vcp_log 是誰的資料表呢？

剛好網路上有人提供 MySQL CPU 使用率高的另一個可能，

就是遭受外部攻擊，有一堆人來試著連資料庫。

雖然 Google Cloud Platform 上的應該不會讓外部來直接連，

但我還是去 WordPress 的外掛 Wordfence 看了一下…

 

看到它回報了一個問題，說 Visitor Counter Plugin 這個外掛，

已經在 wordpress.org 上被移除。

被移除的原因不明，但通常代表它不再被維護，或是有安全性疑慮：

 

這個 Visitor Counter Plugin 是一個訪客人數計數器，

它的縮寫，不就是 vcp 嗎？

而且問題發生時的 SQL 敘述，感覺也蠻像是根據時間、IP 在讀寫人數，

所以 wp_vcp_log 這個資料表，極有可能是 Visitor Counter Plugin 在使用的。

 

到 WordPress 控制台，把 Visitor Counter Plugin 這個外掛停用，再觀察一陣子。

從 atop 看，mysqld 的 CPU 使用率已經不再常常飆高。

而從 Google Cloud Platform 的監控圖表看，

紅線大約是我關掉外掛的時間，那之後 CPU 使用率明顯下降，

而且大約都維持在 5% 左右，跟我另一台正常的機器差不多：

 

去瀏覽 WordPress 網站，也可以明顯感受到速度變快了。

真是太棒了，困擾已久的 CPU 使用率問題終於解決啦～

(不過訪客人數外掛得另外找就是了… @@)

 

參考資料：MySQL high CPU usage – Stack Overflow