คู่มือเกมแลค › L9 โปรเซสเกมฝั่งเซิร์ฟเวอร์
ทิกเกินงบเวลา Tick overrun
ID สาเหตุ sp-tick-overrun · ผู้รับผิดชอบหลัก พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม) · ร่วมกับ อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา)
เปิดการ์ดในฉบับหลักที่มีภาพและการทดลอง →
ถ้างานในหนึ่งทิกเกินงบเวลา รอบทิกของเซิร์ฟเวอร์จะยืดออก และทั้งพื้นที่จะช้าลงหรือกระตุก
ทำไม งานในหนึ่งทิก (เช่น 50 ms) เกินงบเวลา → ผลคือ สถานะเกมที่ควรคำนวณ 20 ครั้งใน 1 วินาที ถูกคำนวณแค่ 8 ครั้ง → บนหน้าจอ ทั้งพื้นที่เป็นสโลว์โมชั่น (แล้วแต่การออกแบบเซิร์ฟเวอร์ อาจเป็นอาการกระตุก), สกิลตอบสนองช้า
- อาการ
- สโลว์โมชั่น, อินพุตดีเลย์, กระตุก
- ปัจจัย
- การหยุดชะงัก
- ใครเจอ
- บางจุด/บางแชนแนล, ทั้งเซิร์ฟเวอร์
- เกิดเมื่อไร
- ตอนคนแห่มารวมกัน, ช่วงพีคหัวค่ำ
- ผู้รับผิดชอบ
- ผู้รับผิดชอบหลัก พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม) · ร่วมกับ อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา)
- งานฝั่งทีมพัฒนาเกม
- ลดการคำนวณที่หนัก, แบ่งงานในทิกไปหลายเธรด, กระจายผู้เล่น (แชนแนล), เก็บเวลาประมวลผลต่อทิกเป็นเมตริก
- งานฝั่งทีมอินฟรา
- เพิ่มเวลาต่อทิกและอัตราการใช้ CPU แยกตามคอร์ในการมอนิเตอร์และ alert, พิจารณา CPU หรืออินสแตนซ์ที่ประสิทธิภาพคอร์เดียว (คล็อก) สูง
- ตัวเลขที่ควรรู้
- งบเวลาของเซิร์ฟเวอร์ 20 ทิกคือ 50 ms, 30 ทิกคือ 33 ms และ 60 ทิกคือ 16.7 ms เพื่อรับมือตอนคนแห่เข้ามากะทันหัน ตามปกติควรใช้แค่ราวครึ่งหนึ่งของงบและเผื่อที่เหลือไว้ จะปลอดภัยกว่า
- บนกราฟ
- สูงตามจำนวนคนและโหลด · เวลาต่อทิกของเซิร์ฟเวอร์, จำนวนผู้เล่นแยกตามโซน/แชนแนล, CPU ของเธรดเกม
- จุดที่ต้องดู
- เวลาประมวลผลต่อทิก (p99) และจำนวนครั้งที่ทิกเกินงบที่เซิร์ฟเวอร์บันทึก วางบนกราฟเดียวกับจำนวนผู้เล่นแยกตามโซน/แชนแนล ถ้าไม่มีเมตริกทิก ให้ดู CPU ของเธรดเกมตัวเดียวด้วย pidstat -t 1
- สัญญาณว่าใช่
- ช่วงที่คนรวมตัวกัน เวลาต่อทิกเกินงบ (50 ms ที่ 20 ทิก) และระหว่างนั้น CPU ของเธรดเกมอยู่ใกล้ 100%
- สัญญาณว่าไม่ใช่
- ทิกเกินงบแต่ CPU ของเธรดเกมต่ำ: น่าจะเป็นสาเหตุฝั่งการรอ (GC pause, ล็อก, synchronous call) ถ้า run queue latency จาก bcc runqlat สูง แปลว่าเธรดไม่ได้รับ CPU: น่าจะเป็น CPU ไม่พอหรือเธรดมากเกินไป
- วิธีตรวจ
- ต้องมี log หรือเมตริกจากเซิร์ฟเวอร์/ไคลเอนต์เกม
- รายละเอียดเพิ่มเติม
- ทิกที่ช้าจะออกมาในลักษณะไหนขึ้นอยู่กับการออกแบบเซิร์ฟเวอร์ เซิร์ฟเวอร์ที่เดินสถานะเกมไปทีละช่วงเวลาคงที่ทุกทิก (เช่น 50 ms) จะทำให้เวลาในเกมเองช้าลงจนเป็นสโลว์โมชั่น ส่วนเซิร์ฟเวอร์ที่ขยับทุกอย่างตามเวลาที่ผ่านไปจริงในครั้งเดียว จะรักษาความเร็วของเกมไว้ได้ แต่แพ็กเก็ตจะมาห่างและแต่ละครั้งขยับไกล จึงเห็นเป็นอาการกระตุกหรือวาร์ป ไม่ว่าแบบไหน การตอบสนองต่ออินพุตก็ช้าลง ถ้าเธรดเกมตัวเดียวดูแลทั้งเซิร์ฟเวอร์ ทั้งเซิร์ฟเวอร์จะช้า ถ้าแยกเธรดตามพื้นที่ พื้นที่นั้นจะช้า บางเกม เช่น EVE Online จงใจทำให้เวลาในเกมช้าลงได้สูงสุด 10 เท่าในศึกใหญ่ (Time Dilation) เพื่อให้การคำนวณตามทัน
- กรณีจริง
- CCP Games 2014: เซิร์ฟเวอร์ EVE Online โหลดเกินในศึกกองยานขนาดใหญ่ที่ HED-GP
แหล่งอ้างอิง
- VALORANT's 128-Tick Servers Riot Games
เซิร์ฟเวอร์ 128 ทิกต้องจบหนึ่งเฟรมภายใน 7.8125 ms, วัดเวลาเฟรมของเซิร์ฟเวอร์แยกตามระบบย่อย และแบ่งงบเวลาให้แต่ละระบบย่อยดูแล - HED-GP Technical Retrospective: What a HED-ache CCP Games
EVE Online ใช้ Time Dilation ทำให้เวลาในเกมช้าลงเมื่อโหลดเกิน โดยต่ำสุดที่ 10% (ช้าลง 10 เท่า), ปกติ CPU ของโหนดอยู่ต่ำกว่า 80% - Handling variation in time Unity
เมื่อการจำลองแบบช่วงเวลาคงที่ (fixed step) ตามไม่ทัน จะรันหลายขั้นติดกันรวดเดียวเพื่อไล่ให้ทัน และทิ้งเวลาส่วนที่เกินขีดจำกัด เวลาในเกมจึงเดินช้ากว่าเวลาจริง - pidstat(1) — Linux manual page sysstat
-t แสดงสถิติแยกตามเธรดของโปรเซส (อัตราการใช้ CPU เป็นต้น) ไปด้วย - Demonstrations of runqlat, the Linux eBPF/bcc version IO Visor
แสดง run queue latency ของ scheduler (เวลาที่งานรอจนได้รับ CPU) เป็นฮิสโทแกรม
สาเหตุที่ควรดูประกอบ
ชั้นเดียวกัน: L9 โปรเซสเกมฝั่งเซิร์ฟเวอร์
สาเหตุจากชั้นอื่นที่ทำให้เกิดอาการเดียวกัน (สโลว์โมชั่น)
ดูการ์ดในฉบับหลักที่มีภาพและการทดลอง