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

磁碟已滿 Disk full

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

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

log 與 dump 越積越多、把磁碟塞滿時，寫入會失敗；沒有防範措施的話，伺服器會當機。

為什麼 log、dump、暫存檔累積到 100% → 於是寫入失敗。沒有錯誤處理就當機，有的話則存檔失敗 → 畫面上 斷線、進度回檔

症狀: 斷線, 吃指令／回檔
因素: 停滯
誰會遇到: 整個伺服器
何時: 開越久越嚴重
負責單位: 主要負責 基礎設施團隊（伺服器基礎設施） · 協同基礎設施團隊（DB 基礎設施）, 遊戲開發團隊（伺服器開發）
遊戲開發團隊要做的事: 處理寫入失敗，改為重試存檔並發出警示，避免當機；減少不必要的 log 與 dump。
基礎設施團隊要做的事: 伺服器設備／OS：log 輪替、容量警示、log 與資料分放不同磁碟。DB 設備：監看 DB 的 transaction log（WAL、binlog）是否因複寫中斷或漏做 log 備份而持續累積。
圖表上: 緩慢爬升 · 磁碟使用率
查看位置: 看 df -h 的使用率與 df -i 的 inode 使用率，並在伺服器與 DB 的 log 中找 ENOSPC 錯誤。DB 方面，看 PostgreSQL pg_replication_slots 中 active 為 false 的複寫槽、MySQL SHOW BINARY LOGS 的檔案數與大小、SQL Server sys.databases 的 log_reuse_wait_desc，RDS 則看 FreeStorageSpace
符合的跡象: 使用率在幾天內持續上升，達到 100% 的時間點與當機、存檔失敗的時間重疊，log 中留有 ENOSPC
不符合的跡象: 空間充足但寫入仍失敗時，是權限、檔案大小上限等其他原因
確認方式: 用基礎設施工具確認（不需要遊戲程式碼）
深入了解: 複本停止或漏做 log 備份時，DB 的 transaction log（WAL、binlog 等）不會被刪除，會一直累積。這顆磁碟滿了以後，DB 的所有寫入都會停止，存檔與交易同時失敗。

出處

write(2) — Linux manual page Linux man-pages
裝置沒有剩餘空間時，寫入會以 ENOSPC 錯誤失敗
Monitoring Disk Usage (PostgreSQL Documentation) PostgreSQL
WAL 磁碟滿了時，DB 伺服器可能會 panic 並關閉
Log-Shipping Standby Servers (PostgreSQL Documentation) PostgreSQL
複寫槽在複本收到之前不會刪除 WAL，因此可能塞滿 pg_wal 的空間（可用 max_slot_wal_keep_size 限制）
Troubleshoot a full transaction log (SQL Server Error 9002) Microsoft SQL Server
log 滿了時 DB 只能讀取、無法修改；漏做 log 備份、複寫延遲、長時間的 transaction 是妨礙 log 清理的常見原因；被什麼卡住可由 sys.databases 的 log_reuse_wait_desc 確認
df(1) — Linux manual page coreutils
各檔案系統的使用量；加上 -i 則改為顯示 inode 使用量
pg_replication_slots (PostgreSQL Documentation) PostgreSQL
active：該複寫槽目前是否正在串流；wal_status：複寫槽保留的 WAL 是否已超過 max_wal_size
SHOW BINARY LOGS Statement MySQL
伺服器的 binary log 檔案清單與檔案大小（File_size）
Amazon CloudWatch metrics for Amazon RDS AWS
FreeStorageSpace：DB 執行個體的剩餘儲存空間

磁碟已滿 Disk full

出處

相關原因

同一層：L11 磁碟

同一症狀（斷線）在其他層的原因