คู่มือเกมแลค › L10 หน่วยความจำ
แคชมิส CPU cache misses
ID สาเหตุ mem-cache-miss · ผู้รับผิดชอบหลัก พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม)
เปิดการ์ดในฉบับหลักที่มีภาพและการทดลอง →
ถ้าข้อมูลกระจัดกระจายอยู่ทั่วหน่วยความจำ CPU ต้องไปรอถึง RAM ที่ช้าทุกครั้ง
ทำไม ออบเจ็กต์กระจัดกระจายเชื่อมกันด้วยพอยน์เตอร์ และถูกเข้าถึงแบบไม่เรียงลำดับ → ผลคือ ไม่มีข้อมูลในแคชของ CPU จึงต้องอ่านจาก RAM ทุกครั้ง (ช้ากว่าราว 100 เท่า) → บนหน้าจอ งานเท่าเดิมแต่ต้นทุนต่อทิกเพิ่มเป็นหลายเท่า ถ้าหนักจะเป็นสโลว์โมชั่น
อาการ สโลว์โมชั่น
ปัจจัย การหยุดชะงัก
ใครเจอ ทั้งเซิร์ฟเวอร์
เกิดเมื่อไร ตลอดเวลา, ตอนคนแห่มารวมกัน
ผู้รับผิดชอบ ผู้รับผิดชอบหลัก พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม)
งานฝั่งทีมพัฒนาเกม จัดข้อมูลที่ใช้คู่กันบ่อยให้อยู่ติดกัน (data-oriented design)
บนกราฟ สูงตลอดตั้งแต่แรก · เวลาต่อทิก, อัตราการใช้ CPU
จุดที่ต้องดู ใช้ perf stat -d -p PID กับโปรเซสเซิร์ฟเวอร์เกมเพื่อวัดจำนวนคำสั่งต่อรอบสัญญาณนาฬิกา (insn per cycle) และ cache miss ของ L1 และ LLC แล้วดูคู่กับเวลาต่อทิกและอัตราการใช้ CPU สัญญาณว่าใช่ CPU ยุ่งตลอดแต่ insn per cycle ต่ำและ LLC miss สูง ถ้าบิลด์ที่เปลี่ยนการจัดวางข้อมูลทำให้เวลาต่อทิกลดลงมากที่จำนวนผู้เล่นเท่ากัน ถือว่ายืนยันได้ สัญญาณว่าไม่ใช่ อัตราการใช้ CPU ต่ำแต่ทิกช้า: น่าจะเป็นสาเหตุที่รออยู่นอก CPU เช่น ล็อกหรือรอ I/O วิธีตรวจ ใช้เครื่องมือฝั่งอินฟรา (ไม่ต้องใช้โค้ดเกม)
แหล่งอ้างอิง Designs, Lessons and Advice from Building Large Distributed Systems (LADIS 2009 keynote) Google แคช L1 ใช้ 0.5 ns, แคช L2 ใช้ 7 ns, หน่วยความจำหลัก 100 ns (ข้อมูลปี 2009): ถ้าต้องไปถึง RAM จะช้ากว่าแคชราวสิบถึงร้อยเท่า perf-stat(1) — Linux manual page perf -p นับ hardware event ของโปรเซสที่รันอยู่และแสดง insn per cycle, -d เพิ่ม event ของแคชข้อมูล L1 และ LLC
สาเหตุที่ควรดูประกอบ
ชั้นเดียวกัน: L10 หน่วยความจำ
สาเหตุจากชั้นอื่นที่ทำให้เกิดอาการเดียวกัน (สโลว์โมชั่น)
ดูการ์ดในฉบับหลักที่มีภาพและการทดลอง