คู่มือเกมแลค › L11 ดิสก์
fsync ทะลัก fsync storms
ID สาเหตุ dk-fsync · ผู้รับผิดชอบหลัก พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม) · ร่วมกับ อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา), อินฟรา DB (ทีมอินฟรา)
เปิดการ์ดในฉบับหลักที่มีภาพและการทดลอง →
ถ้าสั่งให้เขียนข้อมูลลงดิสก์ “แบบแน่นอน” แต่ละครั้งจะใช้เวลา 0.1 ms ถึงหลายสิบ ms แล้วแต่ดิสก์ และถ้ามาพร้อมกันมาก คิวจะยาวขึ้น
ทำไม คำขอเขียนแบบแน่นอนมากระจุกกันจากการเซฟตามรอบและผู้เล่นแห่ล็อกเอาต์ → ผลคือ คิวดิสก์ยาวขึ้น → บนหน้าจอ แลคทุกครั้งที่ถึงเวลาเซฟ, ล็อกเอาต์และย้ายแชนแนลช้า
- อาการ
- กระตุก, อินพุตดีเลย์
- ปัจจัย
- การหยุดชะงัก, ความหน่วง
- ใครเจอ
- ทั้งเซิร์ฟเวอร์
- เกิดเมื่อไร
- เป็นรอบสม่ำเสมอ, ตอนคนแห่มารวมกัน
- ผู้รับผิดชอบ
- ผู้รับผิดชอบหลัก พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม) · ร่วมกับ อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา), อินฟรา DB (ทีมอินฟรา)
- งานฝั่งทีมพัฒนาเกม
- รวมการเซฟให้ทำทีเดียว (หลายการเซฟต่อ fsync หนึ่งครั้ง), กระจายเวลาเซฟ
- งานฝั่งทีมอินฟรา
- เครื่องเซิร์ฟเวอร์/OS: ใช้ SSD สำหรับเซิร์ฟเวอร์ที่มีระบบป้องกันไฟดับ, มอนิเตอร์ความยาวคิวดิสก์และดีเลย์ของ fsync เครื่อง DB: ถ้าการเซฟไปลง DB ให้ดิสก์ log ของ DB ใช้ SSD แบบเดียวกันด้วย, มอนิเตอร์ดีเลย์ของ commit
- ตัวเลขที่ควรรู้
- เวลาต่อครั้งต่างกันไปตามเครื่อง แต่โดยประมาณคือ SSD สำหรับเซิร์ฟเวอร์ (มีระบบป้องกันไฟดับ) 0.1 ms, SSD ทั่วไป 1 ms ถึงหลาย ms, ดิสก์คลาวด์ 1–2 ms และ HDD 10 ms ขึ้นไป ถ้าเธรดเดียวรอทีละครั้ง HDD จะทำได้ไม่ถึง 100 ครั้งใน 1 วินาที
- บนกราฟ
- พุ่งเป็นรอบ · ความยาวคิวดิสก์, ดีเลย์ของ flush และการเขียน
- จุดที่ต้องดู
- f/s และ f_await (จำนวน flush ที่ดิสก์ประมวลผลและเวลาที่ใช้), w/s, aqu-sz และ w_await จาก iostat -x 1 วางซ้อนกับเวลาเซฟตามรอบและเวลาล็อกเอาต์ sysstat รุ่นเก่าแสดง aqu-sz เป็น avgqu-sz ดิสก์คลาวด์ให้ดู VolumeQueueLength และ VolumeAvgWriteLatency ของ EBS
- สัญญาณว่าใช่
- ทุกครั้งที่ถึงเวลาเซฟหรือมีคนแห่ล็อกเอาต์ จำนวน 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 ใช้เวลาเฉลี่ยไม่ถึง 500 µs ต่อ I/O ขนาด 16 KiB - Designs, Lessons and Advice from Building Large Distributed Systems (LADIS 2009 keynote) Google
seek ของ HDD หนึ่งครั้ง 10 ms - 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 ดิสก์
สาเหตุจากชั้นอื่นที่ทำให้เกิดอาการเดียวกัน (กระตุก)
ดูการ์ดในฉบับหลักที่มีภาพและการทดลอง