MySQL高寫延遲

Question

我正在開發一個當前使用AWS服務部署的類社交應用程序。特別是，DB使用MYSQL在RDS上運行。 到目前爲止，我們正在使用有限數量的用戶（主要是朋友）測試應用程序，平均每秒寫入IOPS爲15。

真正的問題與數據庫非常高的寫入延遲有關，該延遲始終高於100ms。 RDS實例是一個db.m3.xlarge，比我們需要的要多得多。

我試圖在一個單獨的實例（DB和EC2的相同配置）中執行負載測試，但即使發送的請求數量高得多，我也無法重現如此高的延遲。所以我認爲這可能是由於表碎片造成的，但我還沒有運行表優化，因爲在此過程中數據庫不可訪問。

您對此問題有任何經驗嗎？

更多信息

• 我們正在使用的MySQL版本5.6.21與INNODB的存儲引擎。
• 整個DB大小約爲100MB

• 最大的表格（稱爲Message）大約有790k行。關於此表，以下查詢

  insert into Message (user_id, creationDate, talk_id, text, id) 
  values (2015, '2015-02-01 16:40:06.737', 18312, 'Some text ', 904870) 
  

  花費了11s來執行。

• 更糟的是，查詢

  insert into Comment (anonymous, user_id, creationDate, deleted, post_id, text, id) 
  values (1, 107347, '2015-02-01 16:40:01.849', 0, 124888, 'Comment text', 265742) 
  

  了14秒，但表評論有大約160K。

  CREATE TABLE `comment` (
      `id` bigint(20) NOT NULL, 
      `anonymous` bit(1) NOT NULL, 
      `creationDate` datetime NOT NULL, 
      `deleted` bit(1) NOT NULL, 
      `text` varchar(1000) COLLATE utf8mb4_unicode_ci NOT NULL, 
      `user_id` bigint(20) NOT NULL, 
      `post_id` bigint(20) NOT NULL, 
      PRIMARY KEY (`id`), 
      KEY `FK_jhvt6d9ap8gxv67ftrmshdfhj` (`user_id`), 
      KEY `FK_apirq8ka64iidc18f3k6x5tc5` (`post_id`), 
      CONSTRAINT `FK_apirq8ka64iidc18f3k6x5tc5` FOREIGN KEY (`post_id`) REFERENCES `post` (`id`), 
      CONSTRAINT `FK_jhvt6d9ap8gxv67ftrmshdfhj` FOREIGN KEY (`user_id`) REFERENCES `kuser` (`id`) 
  ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci; 
  

  和

  CREATE TABLE `message` (
      `id` bigint(20) NOT NULL, 
      `creationDate` datetime NOT NULL, 
      `text` varchar(1000) COLLATE utf8mb4_unicode_ci NOT NULL, 
      `user_id` bigint(20) NOT NULL, 
      `talk_id` bigint(20) NOT NULL, 
      PRIMARY KEY (`id`), 
      KEY `FK_d0j091jvk2y4mmfbadnqlohtf` (`user_id`), 
      KEY `FK_64tr15t6wu5y9u143gxt6o3g2` (`thread_id `), 
      CONSTRAINT `FK_64tr15t6wu5y9u143gxt6o3g2` FOREIGN KEY (`thread_id`) REFERENCES `thread` (`id`), 
      CONSTRAINT `FK_d0j091jvk2y4mmfbadnqlohtf` FOREIGN KEY (`user_id`) REFERENCES `kuser` (`id`) 
  ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci; 
  

  部分地塊

  使用AppDynamics我已經能夠提取以下情節：

這兩個表由產生：

• 等待狀態：是不是查詢結束時間太大？

  

• 頁面緩衝：

  

• 寫延遲和隊列：

  

查詢緩存

+------------------------------+-----------+ 
| Variable_name    | Value  | 
+------------------------------+-----------+ 
| query_cache_limit   | 1048576 | 
| query_cache_min_res_unit  | 4096  | 
| query_cache_size    | 1048576 | 
| query_cache_type    | OFF  | 
| query_cache_wlock_invalidate | OFF  | 
+------------------------------+-----------+ 

感謝您的幫助！

Andrea

Answer 1

我與來自亞馬遜的RDS工程師取得聯繫，他們給了我解決方案。 如此高的延遲是由於性能非常低的存儲類型。實際上，我使用默認的5GB固態硬盤（他們稱之爲GP2），每GB存儲容量爲3 IOPS/s，當我的應用程序需要大約50 IOPS/s甚至更多時，可以達到15 IOPS/s。

因此，他們建議我將存儲類型更改爲Magnetic，它提供100 IOPS/s作爲基準。此外，我還能夠減少實例類型，因爲瓶頸只是磁盤。

由於源磁盤（GP2）的性能非常低，遷移花了約3小時。

希望它可以幫助那裏的人！

Answer 2

您的查詢配置文件顯示「查詢結束」時間非常長。這可能是由一個非常（太）大的query cache造成的。每次執行更新語句（INSERT，DELETE，UPDATE）時，都必須更新查詢緩存（每個從更新表中讀取的查詢都會失效）。