RDS性能下降 - 覆盤 - Honeycomb

RDS性能下降 - 覆盤 - Honeycomb

原文： https://www.honeycomb.io/blog...
譯：祝坤榮

概要

注：除非特別說明，全部時間都是UTC。

5月3號週四， 從00:39:08 UTC（週三 17:39 PDT）咱們經歷了一次Honeycomb服務的大約24分鐘的完全停機。大部分服務恢復時間是2018-05-03 01:02:49，全部面向客戶的服務恢復是在01:07:00。

影響

• 在停機期間，客戶不能登陸或查看Honeycomb服務的圖表。
• 停機期間發送給Honeycomb API的事件被大量拒絕；大約86%的API不能服務，並且大約81%的應該已經提交的事件在停機期間沒有被記錄。(百分比的差距是因爲一個單獨的API能夠處理不一樣的事件而且停機沒有平均影響到全部數據集)
• 因爲Honeycomb API沒有報告成功，一些仍存儲在客戶服務上的事件在Honeycomb API恢復正常後又被從新提交。
• 停機期間大約有15%的事件成功保存

咱們對此次停機影響的每個客戶都十分抱歉。咱們對於數據的管理十分認真，並經過對系統的多項改進措施來確保將來這類的停機事件不會形成數據丟失，並確保咱們在相似的失敗中能夠更快的恢復。

發生了什麼？

過後看，故障鏈只有4點連通：

1. 咱們產品使用的RDS MySQL數據庫實例經歷了一次忽然的和大規模的性能減低； P95(query_time)從11毫秒變成>1000毫秒，同時寫操做吞吐在20秒內從 780/秒降到 5/秒。
2. RDS沒有識別到故障，因此 Mutil-AZ feature沒有激活故障轉移。
3. 因爲增長的query_time致使的延遲， Go的MySQL客戶端鏈接池被等待慢查詢結果的鏈接填滿了而且做爲補償又打開了更多的鏈接。
4. MySQL服務器的max_connections設置達到了上限，致使定時任務和新啓動的後臺進程不能鏈接到數據庫並致使「Error 1040：Too many connections」的日誌信息。

恢復部分很快：

1. RDS數據庫的延遲和吞吐忽然出現改善；在20秒內P95(query_time)寫從>600ms 掉到 <200ms， 同時總吞吐從<500OPS 變成>2500OPS。
2. 排隊的事件快速完成，數據庫在70秒內的OPS大於3000， 並在回到正常狀態時變成： 300-500OPS，<10ms 寫。

咱們如何獲得答案的故事是一個如何使用Honeycomb來debug生產系統的有趣的例子。

根因分析

在以後次日早上咱們的覆盤會議上，兩個理論擺在桌上：

1. 大量的鏈接數致使停機，並引發了數據庫運行緩慢，或
2. 數據庫因爲一些緣由運行緩慢，致使大量的鏈接數。

咱們擔憂一些bug隱藏在咱們的應用裏(或咱們使用的其中一個Go庫)致使咱們的應用在不能鏈接數據庫時關機，這樣在一樣狀況再發生時又會致使同樣的停機故障。
每一個人都贊成這很像是下層數據庫的問題（存儲，CPU或鏈接）是根因，但咱們也贊成若是咱們以抱怨網絡的方式忽略一個潛在應用級的bug會更有危險。

做爲開發者的責任：這可能不是數據庫，而多是你的代碼問題。

爲了下降風險，咱們決定在受控環境來重現Error 1040場景並觀察系統表現。在咱們的實驗集羣上重現鏈接池溢出清楚的代表了鏈接滿確實會影響應用並致使定時任務失敗，它不會致使失控的CPU或延遲升高。

咱們如今有兩個數據集：生產的停機和實驗用的。因爲咱們使用Honeycomb來觀察Honeycomb，因此在這個例子對比A和B很容易

實驗生產停機

左邊，實驗集羣從12:30到13:23（除了一些失敗的定時任務很難看出證據）運行，而在右邊，生產的停機很清楚地顯示着。實驗有個空結果：咱們沒有發現 Error 1040致使了停機。看起來像是系統的一些底層問題致使的。

有了這個信息，咱們須要在生產數據上挖掘的更深刻了。因爲Honeycomb數據集是高保真的（咱們不作任何聚合或預先的計算），能夠將數據調整到每秒級別並調整數據來抽取模式。這裏是從rdslogs裏記錄的性能數據。

有15秒沒有活動，而後有一批query_time值達到了15秒的完成動做，看起來很明顯。在結束時的性能異常也有一個有意思的熱力圖模式：

歸納下，數據展現了高於23分鐘的低吞吐，高延遲行爲，並持續了少於30秒切換區域，以前是正常的高吞吐，低延遲，尖峯應用驅動的行爲，接着是大量的追趕事件，最後切換到正常的高吞吐模式。

因爲這不是一個全面的根因分析，但對於咱們明確問題在數據庫系統而不是咱們的應用代碼已經夠了；咱們的應用看起來運行正常。咱們以後再SQL的normalized_query字符串上驗證了咱們的代碼在恢復過程當中工做符合預期。

獲得這些信息後咱們從新調查了咱們的RDS配置並確認

• Multi-AZ是打開的。
• 實例監視面板沒有顯示任何健康事件。
• AWS文檔指出Multi-AZ不會考慮性能做爲健康檢查的內容

經驗

• 受管理的數據庫很好，除非他們沒託管。
• 咱們會優先考慮在「game day」運行咱們的實驗RDS作故障轉移來從新驗證在硬件故障時咱們對於咱們系統運行的理解。雖然咱們不認爲RDS會有不少硬件故障，但當咱們須要處理RDS AZ故障轉移時咱們須要一個準備好的手冊來執行。
• 咱們在改進咱們的管道來保證在基礎設施不能鏈接到數據庫時接受的用戶事件咱們能夠緩存它們而不是失敗。硬件問題發生，這就是生活；丟失數據不須要發生。

時間線 (2018-05-03 UTC)

00:39 – outage starts

00:40 – first alert

00:42 – engineers start investigation

00:50 – escalation, multiple investigators looking at several potential avenues

00:55 – status.honeycomb.io updated to keep our customers informed

00:58 – first engineering interventions to attempt to heal system, minimal impact

01:03 – outage resolution starts

01:04:23 – resolution completes, system stabilized

01:15 – engineers conclude that outage is resolved, update status.honeycomb.io

---

本文來自微信公衆號「麥芽麪包，id「darkjune_think」轉載請註明。交流Email: zhukunrong@yeah.net