備份、壓縮、掃描作業 Backup / compression / scans

原因 ID dk-backup · 主要負責 基礎設施團隊（伺服器基礎設施） · 協同基礎設施團隊（DB 基礎設施）

凌晨的備份、log 壓縮、安全掃描獨占磁碟時，遊戲伺服器的讀寫就會被擠到後面。

為什麼 排定的備份、壓縮作業開始 → 於是占用大部分的磁碟頻寬與 IOPS → 畫面上 每天同一時間 lag

症狀: 卡頓, 輸入延遲
因素: 停滯, 延遲
誰會遇到: 整個伺服器
何時: 固定週期
負責單位: 主要負責 基礎設施團隊（伺服器基礎設施） · 協同基礎設施團隊（DB 基礎設施）
基礎設施團隊要做的事: 伺服器設備／OS：調低備份、壓縮、掃描作業的 I/O 優先順序，並錯開執行時間。DB 設備：從複本進行備份。
圖表上: 固定週期飆高 · 磁碟使用率、磁碟等待時間
查看位置: 用 sar -d 把過去幾天紀錄（/var/log/sa 的每日檔案，sadc 須以 -S DISK 一併收集磁碟項目）的 %util、await、aqu-sz 按日期疊在一起看，在那個時間點用 pidstat -d 1 找出 kB_rd/s、kB_wr/s 最大的處理程序，再與 cron、systemd timer 的排程比對
符合的跡象: 每天同一時間 await 與 %util 往上衝，此時備份、壓縮、掃描處理程序占了大部分的磁碟讀寫
不符合的跡象: 往上衝的時間每天不同時，不太可能是排程工作。那個時間的 I/O 大多來自遊戲伺服器本身時，是存檔或 log 的問題（dk-fsync、dk-sync-log）
確認方式: 用基礎設施工具確認（不需要遊戲程式碼）

出處

ionice(1) — Linux manual page util-linux
以 idle 類別執行的工作，只有在其他程式沒有使用磁碟時才分得到磁碟時間
Using Replication for Backups MySQL
停下複本來備份，不會影響主 DB 的運作
sar(1) — Linux manual page sysstat
-d：每日紀錄檔（預設 /var/log/sa）中各裝置的 await、aqu-sz、%util；磁碟項目須以 sadc 的 -S DISK 選項收集
pidstat(1) — Linux manual page sysstat
-d：各處理程序的 kB_rd/s、kB_wr/s（每秒磁碟讀取量、寫入量）