遊戲 Lag 白皮書 › L11 磁碟
fsync 暴增 fsync storms
原因 ID dk-fsync · 主要負責 遊戲開發團隊（伺服器開發） · 協同 基礎設施團隊（伺服器基礎設施）, 基礎設施團隊（DB 基礎設施）
在含圖解與實驗的完整版中開啟卡片 →
要求把資料「確實」寫入磁碟時，依磁碟不同，每次需要 0.1ms～數十 ms；請求一多，佇列就會變長。
為什麼 定期存檔、登出潮使確實寫入的請求大量湧入 → 於是 磁碟佇列變長 → 畫面上 每到存檔時間就 lag，登出、切換頻道變慢
- 症狀
- 卡頓, 輸入延遲
- 因素
- 停滯, 延遲
- 誰會遇到
- 整個伺服器
- 何時
- 固定週期, 人潮湧入時
- 負責單位
- 主要負責 遊戲開發團隊（伺服器開發） · 協同 基礎設施團隊（伺服器基礎設施）, 基礎設施團隊（DB 基礎設施）
- 遊戲開發團隊要做的事
- 把多次存檔合併成一次（多筆存檔只呼叫一次 fsync）、分散存檔時間。
- 基礎設施團隊要做的事
- 伺服器設備／OS：採用具斷電保護的伺服器用 SSD，監控磁碟佇列長度與 fsync 延遲。DB 設備：存檔寫入 DB 時，DB 的 log 磁碟也換成同類 SSD，並監控 commit 延遲。
- 數值參考
- 每次所需時間依設備而異，大致是：伺服器用 SSD（具斷電保護）0.1ms、一般 SSD 1～數 ms、雲端磁碟 1～2ms、HDD 10ms 以上。由單一執行緒一個一個等待的話，HDD 每秒連 100 次都做不到。
- 圖表上
- 固定週期飆高 · 磁碟佇列長度、flush 與寫入延遲
- 查看位置
- 把 iostat -x 1 的 f/s、f_await（磁碟處理的 flush 次數與耗時）以及 w/s、aqu-sz、w_await，與定期存檔、登出的時間疊在一起看。舊版 sysstat 把 aqu-sz 顯示為 avgqu-sz。雲端磁碟則看 EBS 的 VolumeQueueLength、VolumeAvgWriteLatency
- 符合的跡象
- 每到存檔時間或登出潮，flush 次數與佇列長度一起往上衝，w_await、f_await 變成平常的好幾倍。此時存檔、切換頻道變慢
- 不符合的跡象
- 在與存檔、登出無關的時間佇列往上衝時，是備份、壓縮（dk-backup）或 IOPS 上限（dk-iops）。flush 次數不變卻變慢時，是 burst credit 耗盡的問題（dk-burst）
- 確認方式
- 用基礎設施工具確認（不需要遊戲程式碼）
出處
- fsync(2) — Linux manual page Linux man-pages
fsync 會連磁碟快取一併清空，並阻塞到裝置回報完成為止 - Reliability (PostgreSQL Documentation) PostgreSQL
一般 SATA 磁碟與許多 SSD 的寫入快取在斷電時會遺失，要確實寫入，需要有電池或斷電保護的快取 - Amazon EBS General Purpose SSD volumes AWS
雲端預設磁碟（gp3）的延遲為個位數 ms，io2 Block Express 在 16KiB I/O 下平均不到 500µs - Designs, Lessons and Advice from Building Large Distributed Systems (LADIS 2009 keynote) Google
HDD 尋軌一次 10ms - iostat(1) — Linux manual page sysstat
-x：f/s、f_await（磁碟處理的 flush 請求數與平均時間）、w/s、w_await、aqu-sz（舊名 avgqu-sz） - Amazon CloudWatch metrics for Amazon EBS AWS
VolumeQueueLength（等待完成的請求數）、VolumeAvgWriteLatency（1 分鐘平均寫入延遲，Nitro 執行個體）
相關原因
同一層：L11 磁碟
同一症狀（卡頓）在其他層的原因
查看含圖解與實驗的完整版卡片