คู่มือเกมแลค › L11 ดิสก์
lazy loading บนเซิร์ฟเวอร์ Lazy loading on the server
ID สาเหตุ dk-lazy-load · ผู้รับผิดชอบหลัก พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม) · ร่วมกับ อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา)
เปิดการ์ดในฉบับหลักที่มีภาพและการทดลอง →
ถ้าเซิร์ฟเวอร์อ่านข้อมูลดันเจี้ยนหรือแมพจากดิสก์ตอนที่ถูกขอเป็นครั้งแรก ทุกคนจะหยุดไปตลอดทิกนั้น
ทำไม มีคนเข้าดันเจี้ยนหรือพื้นที่นั้นเป็นคนแรก → ผลคือ เซิร์ฟเวอร์อ่านข้อมูลจากดิสก์ในเธรดเกม → บนหน้าจอ ทุกคนบนเซิร์ฟเวอร์นั้นค้างไปครู่หนึ่ง
- อาการ
- ค้าง
- ปัจจัย
- การหยุดชะงัก
- ใครเจอ
- บางจุด/บางแชนแนล, ทั้งเซิร์ฟเวอร์
- เกิดเมื่อไร
- ระหว่างเดินทาง/ย้ายแมพ
- ผู้รับผิดชอบ
- ผู้รับผิดชอบหลัก พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม) · ร่วมกับ อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา)
- งานฝั่งทีมพัฒนาเกม
- โหลดล่วงหน้าตอนเซิร์ฟเวอร์เริ่ม, โหลดแบบ async
- งานฝั่งทีมอินฟรา
- เซิร์ฟเวอร์ที่เพิ่งสร้างจากสแนปช็อตให้วอร์มดิสก์ก่อนเปิดให้บริการ (อ่านทุกบล็อกหนึ่งรอบ) หรือใช้ฟีเจอร์ fast snapshot restore
- บนกราฟ
- พุ่งแบบสุ่มเป็นครั้งคราว · เวลาต่อทิกของเซิร์ฟเวอร์, การอ่านดิสก์
- จุดที่ต้องดู
- เทียบช่วงที่หยุดกับรายการเข้าดันเจี้ยนหรือพื้นที่ครั้งแรกใน log ของเซิร์ฟเวอร์เกม และดูการอ่านดิสก์ของเซิร์ฟเวอร์เกมในจังหวะนั้น (kB_rd/s ของ pidstat -d) กับการเรียก read และ open ที่ใช้เวลานานจาก perf trace --duration ถ้าเป็นเซิร์ฟเวอร์คลาวด์ที่เพิ่งเปิด ให้เทียบ VolumeAvgReadLatency ของ EBS กับเซิร์ฟเวอร์ที่เปิดมานาน
- สัญญาณว่าใช่
- หยุดเฉพาะตอนเข้าครั้งแรก เข้าที่เดิมครั้งที่สองไม่หยุด ระหว่างที่หยุด เธรดเกมรอการอ่านไฟล์อยู่
- สัญญาณว่าไม่ใช่
- พื้นที่ที่โหลดไว้แล้วก็หยุดเหมือนกัน: น่าจะเป็นสาเหตุอื่น เช่น ทิกเกินงบหรือ GC
- วิธีตรวจ
- ต้องมี log หรือเมตริกจากเซิร์ฟเวอร์/ไคลเอนต์เกม
- รายละเอียดเพิ่มเติม
- บนคลาวด์ เซิร์ฟเวอร์ที่เพิ่งสร้างจากสแนปช็อต (สำเนาดิสก์) ต้องดึงทุกบล็อกที่อ่านครั้งแรกมาจากสตอเรจระยะไกล จึงช้ากว่าปกติมาก ถ้าการเข้าครั้งแรกนานผิดปกติเฉพาะบนเซิร์ฟเวอร์ที่เพิ่งเปิดขึ้นจาก autoscaling ให้สงสัยสาเหตุนี้
แหล่งอ้างอิง
- Initialize Amazon EBS volumes AWS
volume ที่สร้างจากสแนปช็อตจะมีดีเลย์สูงขึ้นและประสิทธิภาพตกระหว่างดึงบล็อกจาก S3, ใช้ dd หรือ fio อ่านทุกบล็อกเพื่อ initialize ล่วงหน้า - Amazon EBS fast snapshot restore AWS
fast snapshot restore ให้ volume ที่ initialize แล้วตั้งแต่ตอนสร้าง จึงไม่มีดีเลย์ตอนเข้าถึงครั้งแรก - pidstat(1) — Linux manual page sysstat
-d: kB_rd/s ของแต่ละโปรเซส (ปริมาณอ่านดิสก์ต่อวินาที) - perf-trace(1) — Linux manual page perf
--duration แสดงเฉพาะ system call ที่ใช้เวลานานกว่าจำนวน ms ที่กำหนด - Amazon CloudWatch metrics for Amazon EBS AWS
VolumeAvgReadLatency: ดีเลย์การอ่านเฉลี่ยราย 1 นาที (อินสแตนซ์ Nitro)
สาเหตุที่ควรดูประกอบ
ชั้นเดียวกัน: L11 ดิสก์
สาเหตุจากชั้นอื่นที่ทำให้เกิดอาการเดียวกัน (ค้าง)
ดูการ์ดในฉบับหลักที่มีภาพและการทดลอง