MySQL查詢時間出現怪異峰值

Question

我正在為游戲服務器（玩家信息，savedata，內容）運行帶有MySQL（InnoDB）的NodeJS。 服務器基於HTTP（S），因此沒有實時性。

從下面的圖表中可以看到，我出現了這些怪異的峰值（第一個圖表是請求/秒，最后一個圖表是查詢/秒）

在響應時間圖上，您可以看到紫色的最大響應時間和藍色的平均響應時間。 即使出現了10-20k的峰值，平均請求仍會保持在50-100ms，95％的請求也是如此。

我一直在研究，發現慢查詢沒什么特別的。 通常使用savedata（〜2kb的blob）更新查詢或更新播放器配置文件，例如用戶名等。 沒有聯接或類似的東西。 我們正在談論少於10萬行的表。

服務器在具有MySQL 5.7的Ubuntu 14.04上的Azure中使用4個內核和7GB RAM運行。

MySQL設置：

innodb_buffer_pool_size=4G
innodb_log_file_size=1G
innodb_buffer_pool_instances=4
innodb_log_buffer_size=4M
query_cache_type=0
tmp_table_size=64M
max_heap_table_size=64M
sort_buffer_size=32M
wait_timeout=300
interactive_timeout=300
innodb_file_per_table=ON

編輯：原來問題不是SQL查詢之前的MySQL性能而是Node.js性能。 更多信息在這里： Node.js multer和body-parser有時非常慢

Answer 1

檢查您的交換能力（假設是0台mysql機器，以最大化ram使用率）：

> sysctl -A|grep swap
vm.swappiness = 0

只有7G的RAM和4G的緩沖池，如果swappiness不為零，您的計算機將進行交換。

您可以發布交換圖和使用的內存嗎？ 對於7G內存，4G緩沖區“處於邊緣”。 對於8G內存，我會給3G，因為您在其他所有mysql wise上的+ 1G以及在OS上的2G。

另外，您有1G的事務日志文件，我假設您有兩個日志文件。 您有這么大的文件寫這么多嗎？ 您可以使用此指南： https : //www.percona.com/blog/2008/11/21/how-to-calculate-a-good-innodb-log-file-size/