我們在db.t2.large實例上使用RDS。而EC2的自動縮放組在白天將數據寫入數據庫。在繁忙時間，我們有大約50,000個HTTP請求，每個請求讀取/寫入MySQL數據。高峯時段RDS連接超時（約50,000個HTTP請求）
這每一天變化，但對於今天的例子，一個小時內：
我們看到從我們的PHP的情況下，一分鐘約187次「連接錯誤（2002）連接超時」。
- RDS CPU不會提高50％以上
- DB連接將不會高於30（最大設置爲5000）。
- 免費存儲空間約爲300G（磁盤空間較大以提供較高的IOPS）
- 寫入IOPS命中1500個爆發，但降至900個，因爲突發限制在高峯時間後已過期。
- 閱讀IOPS每10分鐘觸及300次，大約在150次之間。 20和25 MB /秒
- 磁盤0,75和1,5 MB之間讀取吞吐量/秒之間
- 磁盤寫入吞吐量平均
- CPU信貸餘額爲500左右，所以我們沒有必要CPU爆裂。
而且，當涉及到網絡，我看到我們打一個潛在的限制：
- 網絡接收吞吐量達到1.41 MB /秒，一小時期間保持約1.5 MB /秒。
- 在這段時間內網絡發送5 5.2兆字節/秒與下降至4個MB /秒每次10分鐘，其與我們的cronjobs被處理數據（主要是讀取）
我試圖放置EC2的同意在不同的或相同的AZ中，但這沒有效果
在此期間，我可以通過SSH隧道（EC2-> RDS）從本地工作站正常連接。從EC2到RDS也是如此。
PHP腳本在嘗試連接5秒後設置爲超時，以確保快速響應。對於某些腳本，我現在已將此限制提高到15秒。
但是我們在RDS上遇到了哪些限制？在開始遷移或更改實例類型之前，我們希望知道此問題的來源。我剛剛啓用了增強監控功能，以獲取有關此問題的更多詳細信息。
如果需要更多信息，我會很樂意詳細說明需要的地方。
謝謝！
更新25/01/2016
在datasage我們增加了RDS磁盤大小500 GB這讓我們有3600爆1500次IOPS的建議，它使用了大約1200個IOPS（因此，即使不是現在爆破）並且超時仍然發生。
如前所述，連接超時設置爲5秒和15秒，顯示沒有區別。
更新26/01/2016
RDS截圖來自我們的高峯時段：
更新28/01/2016
我已經改變了設置sync_bin_log爲0，因爲最初我以爲我們碰到了EBS吞吐量限制（GP-SSD 160 Mbit/s），這給了我們一個信號磁盤吞吐量和IOPS的下降同樣較低，但我們仍然看到連接超時發生。
當我們繪製錯誤發生的時間時，我們看到每分鐘一次：40秒超時在約25秒內開始發生，然後再次沒有錯誤再過35秒，然後重新開始。這在我們傳入流量的高峯時段。
T2實例使用信用模型。在遇到超時時，貸方餘額是什麼樣的？ – datasage
由於我已經注意到CPU信用餘額，所以我改進了問題的格式:-) CPU信用額大約是500，並沒有大幅下降。 – Nick
在這種情況下，您會看到您達到IOPS限制。通用SSD每GB有3個IOP。這包括讀寫。如果您無法減少IOP，則可能需要查看切換到預配置的IOPS – datasage