한국어 English 日本語简体中文繁體中文 Deutsch ไทย Tiếng Việt Русский Português (Brasil)Español Bahasa Indonesia

冷快取（剛重新啟動時） Cold buffer pool after restart

原因 ID db-cold-cache · 主要負責 基礎設施團隊（DB 基礎設施） · 協同遊戲開發團隊（伺服器開發）

在含圖解與實驗的完整版中開啟卡片 →

DB 重新啟動後記憶體快取是空的，有一段時間所有查詢都要從磁碟讀取。

為什麼 因維護而重新啟動 DB → 於是常用資料不在記憶體中，只能從磁碟讀取 → 畫面上 維護剛結束的一段時間內，登入、載入很慢

症狀: 連不上／無限讀取, 輸入延遲
因素: 延遲
誰會遇到: 整個伺服器
何時: 剛登入／維護剛結束
負責單位: 主要負責 基礎設施團隊（DB 基礎設施） · 協同遊戲開發團隊（伺服器開發）
遊戲開發團隊要做的事: 逐步開放（用登入排隊分階段增加登入人數）。
基礎設施團隊要做的事: 重新啟動後預熱快取（warm-up，確認 buffer pool 的儲存與還原設定），從快照還原的 DB 也要預先讀取磁碟。
圖表上: 剛開服或維護結束後暴增 · 磁碟讀取、緩衝快取命中率
查看位置: MySQL 看 Innodb_buffer_pool_reads（不在 buffer pool 中而從磁碟讀取的次數）與 Innodb_buffer_pool_read_requests 的比例，以及預熱進度 Innodb_buffer_pool_load_status。PostgreSQL 看 pg_stat_database 的 blks_read、blks_hit。也一併看 DB 伺服器的磁碟讀取次數
符合的跡象: 剛重新啟動時磁碟讀取往上衝、命中率偏低，之後隨時間逐漸恢復，這段期間登入、載入很慢
不符合的跡象: 命中率與平常相同、維護剛結束卻很慢時，是登入暴增與 N+1（db-login-storm）或連線池（db-pool）
確認方式: 用基礎設施工具確認（不需要遊戲程式碼）
深入了解: MySQL 關閉時會儲存 buffer pool 的頁面清單，啟動時在背景重新讀回，但要全部填滿仍需要時間。在雲端上從快照（磁碟副本）還原的 DB，磁碟本身在每個區塊第一次讀取時也很慢，變慢的時間會拖得更久。
實際案例: Roblox 2021: Roblox 73 小時事故：服務探索（Consul）叢集的資源競爭

出處

Saving and Restoring the Buffer Pool State MySQL
為了縮短重新啟動後的預熱時間，關閉時儲存最近使用的頁面清單（預設 25%），啟動時重新讀回；兩者預設都開啟
pg_prewarm — preload relation data into buffer caches PostgreSQL
定期記錄共享緩衝區（shared buffers）的內容，重新啟動後再載回（autoprewarm）
Initialize Amazon EBS volumes AWS
從快照建立的磁碟區，在取回所有區塊之前延遲增加、效能下降
Server Status Variables MySQL
Innodb_buffer_pool_reads（不在 buffer pool 中、直接從磁碟讀取的邏輯讀取次數）、Innodb_buffer_pool_read_requests、Innodb_buffer_pool_load_status（預熱進度）
The Cumulative Statistics System (PostgreSQL Documentation) PostgreSQL
pg_stat_database 的 blks_read（從磁碟讀取的區塊數）、blks_hit（在緩衝快取中找到的區塊數）

冷快取（剛重新啟動時） Cold buffer pool after restart

出處

相關原因

同一層：L12 資料庫

同一症狀（連不上／無限讀取）在其他層的原因