คู่มือเกมแลค › L11 ดิสก์
ขีดจำกัด IOPS/คิวดิสก์อิ่มตัว IOPS limit / queue saturation
ID สาเหตุ dk-iops · ผู้รับผิดชอบหลัก อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา) · ร่วมกับ พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม), อินฟรา DB (ทีมอินฟรา)
เปิดการ์ดในฉบับหลักที่มีภาพและการทดลอง →
ถ้าคำขอเกินจำนวนที่ดิสก์ประมวลผลได้ใน 1 วินาที คิวจะยาวขึ้นและดีเลย์พุ่งสูง
ทำไม คำขออ่านและเขียนเข้าใกล้ขีดความสามารถของดิสก์ → ผลคือ คิวยาวขึ้น (มักพุ่งเมื่ออัตราการใช้งานเกิน 90%) → บนหน้าจอ เซฟและโหลดช้า ถ้าเป็น synchronous call เกมจะค้าง
- อาการ
- อินพุตดีเลย์, ค้าง
- ปัจจัย
- ความหน่วง, การหยุดชะงัก
- ใครเจอ
- ทั้งเซิร์ฟเวอร์
- เกิดเมื่อไร
- ตอนคนแห่มารวมกัน, ช่วงพีคหัวค่ำ
- ผู้รับผิดชอบ
- ผู้รับผิดชอบหลัก อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา) · ร่วมกับ พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม), อินฟรา DB (ทีมอินฟรา)
- งานฝั่งทีมพัฒนาเกม
- รวมคำขอเข้าด้วยกัน, แคชข้อมูลที่อ่านบ่อย, ทำเป็น async เพื่อไม่ให้เธรดเกมรอดิสก์
- งานฝั่งทีมอินฟรา
- เครื่องเซิร์ฟเวอร์/OS: ใช้ดิสก์ที่เร็วขึ้น, ตรวจขีดจำกัดแบนด์วิดท์ดิสก์และ IOPS ของแต่ละประเภทอินสแตนซ์, ตั้ง alert อัตราการใช้งานดิสก์และคิว, คัดลอกไฟล์ใหญ่ในช่วงที่ว่าง เครื่อง DB: ตั้ง alert อัตราการใช้ IOPS และ throughput ของดิสก์ DB ด้วย, ตรวจขีดจำกัดดิสก์ตามสเปกของอินสแตนซ์ DB
- ตัวเลขที่ควรรู้
- HDD ประมาณ 150, SATA SSD หลายหมื่น และ NVMe หลายแสน IOPS ดิสก์คลาวด์พื้นฐาน (AWS gp3) ได้ 3,000 IOPS และ 125 MiB ต่อวินาที ขีดจำกัดปริมาณรับส่งต่อวินาทีแยกจาก IOPS ถ้าการคัดลอกไฟล์ใหญ่ใช้จนเต็ม แม้การเขียนเล็ก ๆ ก็ต้องรอคิวไปด้วย
- บนกราฟ
- ชนเพดานแล้วแบนราบ · IOPS, ความยาวคิวดิสก์
- จุดที่ต้องดู
- r/s, w/s, rkB/s, wkB/s, aqu-sz, r_await และ w_await จาก iostat -x 1 บนคลาวด์ดู VolumeReadOps, VolumeWriteOps และ VolumeQueueLength ของ EBS กับตัวบอกว่าเกินขีดจำกัดหรือไม่ คือ VolumeIOPSExceededCheck และ VolumeThroughputExceededCheck ส่วนฝั่งอินสแตนซ์ดู InstanceEBSIOPSExceededCheck และ InstanceEBSThroughputExceededCheck
- สัญญาณว่าใช่
- จำนวนคำขอต่อวินาทีหรือปริมาณรับส่งแบนราบที่ค่าขีดจำกัด และ aqu-sz กับ await พุ่งขึ้นพร้อมกัน บนคลาวด์เมตริกตรวจการเกินขีดจำกัดเป็น 1
- สัญญาณว่าไม่ใช่
- แม้ %util เป็น 100% ถ้า await ต่ำก็อาจยังมีกำลังเหลือ บน SSD และ RAID ที่ประมวลผลคำขอแบบขนาน %util ไม่ได้บอกขีดจำกัด ถ้ายังไม่ถึงขีดจำกัดแต่ await สูงอย่างเดียว น่าจะเป็นดีเลย์ของตัวดิสก์เอง (dk-hdd) หรือ fsync (dk-fsync)
- วิธีตรวจ
- ใช้เครื่องมือฝั่งอินฟรา (ไม่ต้องใช้โค้ดเกม)
- รายละเอียดเพิ่มเติม
- บนคลาวด์ นอกจากขีดจำกัดของดิสก์แล้ว สเปกเซิร์ฟเวอร์แต่ละแบบ (ประเภทอินสแตนซ์) ยังมีขีดจำกัดแบนด์วิดท์ดิสก์และ IOPS ของตัวเอง ต่อให้ใช้ดิสก์ราคาแพง ถ้าเซิร์ฟเวอร์เล็กก็จะติดที่ขีดจำกัดของอินสแตนซ์
แหล่งอ้างอิง
- Exos X18 Data Sheet Seagate
HDD สำหรับเซิร์ฟเวอร์ 7,200 rpm อ่านแบบสุ่ม 4K ได้ 170 IOPS (QD16) - D3-S4520 SSD Solidigm
SATA SSD สำหรับเซิร์ฟเวอร์ อ่าน/เขียนแบบสุ่ม 4 KB สูงสุด 92K/48K IOPS - Solidigm™ D7-P5520 and D7-P5620 Product Brief Solidigm
NVMe SSD สำหรับเซิร์ฟเวอร์ อ่าน/เขียนแบบสุ่ม 1,000K/200K IOPS - Amazon EBS General Purpose SSD volumes AWS
ประสิทธิภาพพื้นฐานของ gp3 คือ 3,000 IOPS และ 125 MiB/s เป็นขีดจำกัดสองตัวที่แยกกันและเพิ่มแยกกันได้ - Amazon EBS-optimized instance types AWS
แต่ละประเภทอินสแตนซ์มีขีดจำกัดพื้นฐานและสูงสุดของแบนด์วิดท์ EBS, throughput และ IOPS แยกกัน - iostat(1) — Linux manual page sysstat
-x: r/s, w/s, rkB/s, wkB/s, aqu-sz (ชื่อเดิมคือ avgqu-sz), r_await, w_await, %util บน RAID และ SSD รุ่นใหม่ที่ประมวลผลคำขอแบบขนาน %util ไม่ได้บอกขีดจำกัดของประสิทธิภาพ - Amazon CloudWatch metrics for Amazon EBS AWS
VolumeIOPSExceededCheck และ VolumeThroughputExceededCheck: เป็น 1 ถ้ามีการพยายามใช้เกินขีดจำกัด IOPS หรือ throughput ของ volume (อินสแตนซ์ Nitro), VolumeQueueLength - CloudWatch metrics that are available for your instances AWS
InstanceEBSIOPSExceededCheck และ InstanceEBSThroughputExceededCheck: เป็น 1 ถ้ามีการพยายามใช้เกินขีดจำกัด EBS IOPS หรือ throughput ของอินสแตนซ์
สาเหตุที่ควรดูประกอบ
ชั้นเดียวกัน: L11 ดิสก์
สาเหตุจากชั้นอื่นที่ทำให้เกิดอาการเดียวกัน (อินพุตดีเลย์)
ดูการ์ดในฉบับหลักที่มีภาพและการทดลอง