คู่มือเกมแลค › L11 ดิสก์
burst credit ของดิสก์คลาวด์หมด Burst credit depletion
ID สาเหตุ dk-burst · ผู้รับผิดชอบหลัก อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา) · ร่วมกับ อินฟรา DB (ทีมอินฟรา)
เปิดการ์ดในฉบับหลักที่มีภาพและการทดลอง →
ดิสก์คลาวด์บางประเภทและเซิร์ฟเวอร์สเปกเล็กมี burst credit ที่ให้ทำงานเร็วกว่าประสิทธิภาพพื้นฐานได้ชั่วคราว ถ้าช่วงที่ยุ่งยาวนานจนเครดิตหมด ความเร็วจะตกลงกะทันหัน
ทำไม ใช้งานเกินประสิทธิภาพพื้นฐานเป็นเวลานาน → ผลคือ burst credit หมด ประสิทธิภาพจึงดิ่งลงไปเหลือระดับพื้นฐาน → บนหน้าจอ ทุกเย็นพอผ่านไปไม่กี่ชั่วโมงก็เริ่มแลค
อาการ กระตุก , สโลว์โมชั่น , อินพุตดีเลย์ ปัจจัย การหยุดชะงัก, ความหน่วง
ใครเจอ ทั้งเซิร์ฟเวอร์
เกิดเมื่อไร ช่วงพีคหัวค่ำ, ยิ่งเปิดไว้นานยิ่งเป็น
ผู้รับผิดชอบ ผู้รับผิดชอบหลัก อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา) · ร่วมกับ อินฟรา DB (ทีมอินฟรา)
งานฝั่งทีมอินฟรา เครื่องเซิร์ฟเวอร์/OS: ใช้ดิสก์แบบรับประกันประสิทธิภาพ (gp3 หรือแบบกำหนด IOPS), ตั้ง alert เครดิตคงเหลือ, ตรวจขีดจำกัด burst ของแบนด์วิดท์ดิสก์ของอินสแตนซ์และ CPU credit ไปด้วย เครื่อง DB: เปลี่ยนดิสก์ DB รวมถึง managed DB เป็นแบบรับประกันประสิทธิภาพด้วย, ตั้ง alert เครดิตคงเหลือ
ตัวเลขที่ควรรู้ ดิสก์ AWS gp2 ขนาด 100 GB ปกติได้ 300 IOPS และ burst ได้ 3,000 IOPS ถ้าเครดิตเต็มจะอยู่ได้ประมาณ 30 นาที ส่วน gp3 ไม่มีเครดิตและได้ 3,000 เสมอ Premium SSD ขนาดเล็กของ Azure ก็ burst ด้วยเครดิตได้สูงสุด 30 นาทีเช่นกัน
บนกราฟ จุดที่ต้องดู BurstBalance ของ EBS ใน CloudWatch (gp2, st1, sc1), EBSIOBalance% และ EBSByteBalance% ของอินสแตนซ์ (บางอินสแตนซ์ที่ burst ได้), CPUCreditBalance ของอินสแตนซ์แบบ burstable ส่วน Azure ดูเมตริกอัตราการใช้ burst credit เช่น Data Disk Used Burst IO Credits Percentage สัญญาณว่าใช่ ตั้งแต่ช่วงที่เครดิตคงเหลือลดลงใกล้ 0 IOPS (VolumeReadOps, VolumeWriteOps) แบนราบที่ระดับประสิทธิภาพพื้นฐาน และ VolumeQueueLength กับแลคเพิ่มขึ้นพร้อมกัน เริ่มหลังจากพีคต่อเนื่องมาแล้วหลายชั่วโมง สัญญาณว่าไม่ใช่ เครดิตคงเหลือทุกตัวยังมีพอแต่ IOPS แบนราบ: ขีดจำกัดคงที่ของ volume หรืออินสแตนซ์ (dk-iops) วิธีตรวจ ใช้เครื่องมือฝั่งอินฟรา (ไม่ต้องใช้โค้ดเกม)
รายละเอียดเพิ่มเติม แม้ดิสก์จะปกติ VM ขนาดเล็กก็มีขีดจำกัด burst ที่แบนด์วิดท์ดิสก์ของอินสแตนซ์เอง (เช่น อย่างน้อย 30 นาทีต่อวัน) จึงเกิดรูปแบบเดียวกันได้ เซิร์ฟเวอร์ราคาถูกที่ใช้ CPU credit ก็ช้าลงจนเหลือประสิทธิภาพพื้นฐานเมื่อเครดิตหมด
แหล่งอ้างอิง Amazon EBS General Purpose SSD volumes AWS ประสิทธิภาพพื้นฐานของ gp2 คือ 3 IOPS ต่อ GiB (ขั้นต่ำ 100), burst ได้ถึง 3,000 IOPS ด้วย I/O credit, เครดิต 5,400,000 หน่วยอยู่ได้อย่างน้อย 30 นาที gp3 ไม่มี burst และได้ 3,000 IOPS เสมอ Managed disk bursting Microsoft Azure Premium SSD ตั้งแต่ P20 ลงไป burst ด้วยระบบเครดิต, ถ้าเครดิตเต็มจะ burst ที่ความเร็วสูงสุดได้ 30 นาที Amazon EBS-optimized instance types AWS บางอินสแตนซ์คงประสิทธิภาพ EBS สูงสุดได้เพียง 30 นาทีครั้งเดียวใน 24 ชั่วโมง จากนั้นกลับไปที่ประสิทธิภาพพื้นฐาน Standard mode for burstable performance instances AWS อินสแตนซ์แบบ burstable ในโหมด standard จะลดอัตราการใช้ CPU ลงสู่ระดับพื้นฐานเมื่อ CPU credit หมด (ค่อย ๆ ลดเพื่อไม่ให้ดิ่งลงทันที) Amazon CloudWatch metrics for Amazon EBS AWS BurstBalance: I/O credit คงเหลือของ gp2 และ throughput credit คงเหลือของ st1 และ sc1 (%), VolumeReadOps, VolumeWriteOps, VolumeQueueLength CloudWatch metrics that are available for your instances AWS EBSIOBalance% และ EBSByteBalance%: EBS credit คงเหลือของบางอินสแตนซ์ที่ burst ได้ 30 นาทีครั้งเดียวใน 24 ชั่วโมง, CPUCreditBalance: CPU credit คงเหลือของอินสแตนซ์แบบ burstable Disk metrics Microsoft Azure อัตราการใช้ burst credit ของดิสก์และ VM เช่น Data Disk Used Burst IO Credits Percentage (ทุก 5 นาที) สาเหตุที่ควรดูประกอบ
ชั้นเดียวกัน: L11 ดิสก์
สาเหตุจากชั้นอื่นที่ทำให้เกิดอาการเดียวกัน (กระตุก)
ดูการ์ดในฉบับหลักที่มีภาพและการทดลอง