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

คู่มือเกมแลค › L12 ฐานข้อมูล

checkpoint/log flush Checkpoint / log flush stalls

ID สาเหตุ db-checkpoint · ผู้รับผิดชอบหลัก อินฟรา DB (ทีมอินฟรา)

เปิดการ์ดในฉบับหลักที่มีภาพและการทดลอง →

จังหวะที่ DB เขียนส่วนที่เปลี่ยนแปลงในหน่วยความจำลงดิสก์รวดเดียวตามรอบ คิวรีจะช้าลง

ทำไม ส่วนที่เปลี่ยนแปลงสะสมแล้วถูกเขียนลงดิสก์ตามรอบ → ผลคือ ช่วงนั้นดิสก์ยุ่ง คิวรีจึงช้า → บนหน้าจอ เซฟและโหลดช้าลงเป็นรอบ

อาการ
อินพุตดีเลย์, กระตุก
ปัจจัย
ความหน่วง
ใครเจอ
ทั้งเซิร์ฟเวอร์, เฉพาะบางฟีเจอร์
เกิดเมื่อไร
เป็นรอบสม่ำเสมอ
ผู้รับผิดชอบ
ผู้รับผิดชอบหลัก อินฟรา DB (ทีมอินฟรา)
งานฝั่งทีมอินฟรา
แบ่ง checkpoint เป็นช่วงเล็ก ๆ ให้สม่ำเสมอ, ตั้ง transaction log (redo log, WAL) ให้ใหญ่พอ, ใช้ดิสก์ที่เร็ว
บนกราฟ
พุ่งเป็นรอบ · ดีเลย์ของคิวรี DB, ปริมาณการเขียนดิสก์
จุดที่ต้องดู
PostgreSQL ดูเวลา checkpoint และจำนวนบัฟเฟอร์ที่เขียนจาก log ของ log_checkpoints (เวอร์ชันใหม่เปิดเป็นค่าเริ่มต้น), จำนวนครั้งของ checkpoint (ตั้งแต่ 17 คือ num_timed และ num_requested ใน pg_stat_checkpointer, 16 ลงไปคือ checkpoints_timed และ checkpoints_req ใน pg_stat_bgwriter) และคำเตือน checkpoint_warning ส่วน MySQL ดูส่วนต่างระหว่าง Log sequence number กับ Last checkpoint at ในส่วน LOG ของ SHOW ENGINE INNODB STATUS วางซ้อนกับปริมาณการเขียนและดีเลย์การเขียนดิสก์ของเซิร์ฟเวอร์
สัญญาณว่าใช่
ช่วงที่ดีเลย์ของคิวรีพุ่งตรงกับเวลา checkpoint และตอนนั้นปริมาณการเขียนกับดีเลย์การเขียนดิสก์พุ่งขึ้น ใน PostgreSQL ถ้า checkpoint ตามคำขอ (num_requested) มากกว่า checkpoint ตามเวลา (num_timed) มาก ถือว่า WAL แตะ max_wal_size บ่อยจน checkpoint มาเร็วกว่ากำหนด
สัญญาณว่าไม่ใช่
พุ่งเป็นรอบที่ไม่เกี่ยวกับเวลา checkpoint: น่าจะเป็นการสำรองข้อมูลหรืองาน batch (dk-backup, db-batch)
วิธีตรวจ
ใช้เครื่องมือฝั่งอินฟรา (ไม่ต้องใช้โค้ดเกม)
รายละเอียดเพิ่มเติม
ถ้าตั้ง transaction log ที่เก็บบันทึกการเปลี่ยนแปลง (redo log ของ MySQL, WAL ของ PostgreSQL) เล็กเกินไป ทุกครั้งที่ log เต็ม DB ต้องรีบทำ checkpoint รวดเดียว throughput การเขียนจึงตกฮวบเป็นพัก ๆ

แหล่งอ้างอิง

  1. WAL Configuration (PostgreSQL Documentation) PostgreSQL
    checkpoint เกิดทุก 5 นาทีหรือทุก WAL 1 GB (max_wal_size) ตามค่าเริ่มต้น และแพงเพราะต้องเขียน dirty page ทั้งหมด checkpoint_completion_target กระจายการเขียนเพื่อเลี่ยง I/O พุ่ง ถ้าช่วงห่างระหว่าง checkpoint สั้นกว่า checkpoint_warning จะเขียนคำเตือนใน log ให้เพิ่ม max_wal_size
  2. Configuring Buffer Pool Flushing MySQL
    เมื่อ redo log เต็มจะเกิด sharp checkpoint ทำให้ throughput ตกชั่วครู่, adaptive flushing กระจายการเขียนให้สม่ำเสมอ
  3. Error Reporting and Logging (PostgreSQL Documentation) PostgreSQL
    log_checkpoints: เขียนจำนวนบัฟเฟอร์ที่เขียนและเวลาที่ใช้ของทุก checkpoint ลง log, ค่าเริ่มต้นเปิด
  4. The Cumulative Statistics System (PostgreSQL Documentation) PostgreSQL
    num_timed (checkpoint ที่ทำเพราะถึงเวลา) และ num_requested (checkpoint ที่ถูกร้องขอ) ใน pg_stat_checkpointer
  5. PostgreSQL 17 Release Notes PostgreSQL
    เพิ่ม pg_stat_checkpointer ใหม่ และย้ายคอลัมน์เกี่ยวกับ checkpoint มาจาก pg_stat_bgwriter
  6. The Cumulative Statistics System (PostgreSQL 16 Documentation) PostgreSQL
    ถึงเวอร์ชัน 16 ใช้ checkpoints_timed และ checkpoints_req ใน pg_stat_bgwriter
  7. InnoDB Standard Monitor and Lock Monitor Output MySQL
    ส่วน LOG: log sequence number ปัจจุบันและตำแหน่ง checkpoint ล่าสุด

สาเหตุที่ควรดูประกอบ

ชั้นเดียวกัน: L12 ฐานข้อมูล

สาเหตุจากชั้นอื่นที่ทำให้เกิดอาการเดียวกัน (อินพุตดีเลย์)

ดูการ์ดในฉบับหลักที่มีภาพและการทดลอง