คู่มือเกมแลค › L7 OS ของเซิร์ฟเวอร์ (เคอร์เนล)
นาฬิการะบบกระโดด (NTP step) Wall-clock jump (NTP step)
ID สาเหตุ so-timejump · ผู้รับผิดชอบหลัก พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม) · ร่วมกับ อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา)
เปิดการ์ดในฉบับหลักที่มีภาพและการทดลอง →
ถ้านาฬิกาของเซิร์ฟเวอร์ถูกปรับไปข้างหน้าหรือถอยหลังหลายวินาทีในครั้งเดียว ตัวจับเวลาที่อิงนาฬิการะบบจะทำงานพร้อมกันรวดเดียวหรือหยุดไป
ทำไม การซิงก์เวลาปรับนาฬิกาครั้งใหญ่ในครั้งเดียว → ผลคือ ตัวจับเวลาทำงานรวดเดียวหรือหยุด และตัดสินไทม์เอาต์ผิด → บนหน้าจอ บัฟและคูลดาวน์ผิดปกติ, หลุดพร้อมกันหลายคน, กรอเร็ว
- อาการ
- กรอเร็ว, หลุด, กดไม่ติด/โรลแบ็ค
- ปัจจัย
- การหยุดชะงัก
- ใครเจอ
- ทั้งเซิร์ฟเวอร์
- เกิดเมื่อไร
- สุ่มเป็นครั้งคราว
- ผู้รับผิดชอบ
- ผู้รับผิดชอบหลัก พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม) · ร่วมกับ อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา)
- งานฝั่งทีมพัฒนาเกม
- คำนวณเวลาที่ผ่านไป ไทม์เอาต์ และคูลดาวน์ด้วย monotonic clock ที่ไม่กระโดดและไม่ถอยหลัง, ใช้ wall clock เฉพาะการแสดงผลและการบันทึก log
- งานฝั่งทีมอินฟรา
- ปรับนาฬิกาแบบค่อยเป็นค่อยไป (ใช้ makestep ของ chrony เฉพาะตอนเพิ่งเริ่มทำงาน), มอนิเตอร์สถานะการซิงก์เวลา (ความต่างของนาฬิกา)
- ตัวเลขที่ควรรู้
- ntpd จะปรับทีเดียวเมื่อต่างเกิน 0.128 วินาที ถ้าน้อยกว่านั้นจะค่อย ๆ ปรับด้วยอัตราที่ต้องใช้เวลา 30 นาทีเศษในการลบความต่าง 1 วินาที ส่วน chrony ที่นิยมใช้ในปัจจุบัน เมื่อใช้การตั้งค่าที่แนะนำ (makestep) จะปรับทีเดียวเพียงไม่กี่ครั้งหลังเริ่มทำงาน จากนั้นจะค่อย ๆ ปรับ นาฬิกายังกระโดดได้เมื่อ VM หยุดชั่วครู่แล้วกลับมาทำงาน
- บนกราฟ
- พุ่งแบบสุ่มเป็นครั้งคราว · จำนวนครั้งที่ตัวจับเวลาทำงานและจำนวนการหลุด, บันทึกการปรับนาฬิกา
- จุดที่ต้องดู
- บันทึกการปรับนาฬิกาครั้งใหญ่ใน log ของเซอร์วิสซิงก์เวลา เทียบกับเวลาที่เกิดปัญหา chrony จะเขียนลง syslog เมื่อปรับมากกว่าค่า logchange (ค่าเริ่มต้น 1 วินาที)
- สัญญาณว่าใช่
- มีบันทึกการปรับนาฬิกาตรงกับเวลาที่บัฟและคูลดาวน์ผิดปกติ หลุดพร้อมกัน หรือกรอเร็ว และขนาดที่ปรับใกล้เคียงกับขนาดความผิดปกติ
- สัญญาณว่าไม่ใช่
- ไม่มีบันทึกการปรับนาฬิกา: ไม่ใช่สาเหตุนี้ ถ้าเป็น VM ให้ดูกรณีที่หยุดแล้วกลับมาทำงานด้วย (“การซ่อมบำรุงโฮสต์คลาวด์/live migration”)
- วิธีตรวจ
- ใช้เครื่องมือฝั่งอินฟรา (ไม่ต้องใช้โค้ดเกม)
แหล่งอ้างอิง
- ntpd - Network Time Protocol (NTP) daemon Network Time Foundation
ถ้าต่างเกินเกณฑ์ step 128 ms จะปรับทีเดียว ถ้าน้อยกว่าจะค่อย ๆ ปรับ ด้วยอัตรา 0.5 ms ต่อวินาที การปรับ 1 วินาทีจึงใช้ 2,000 วินาที (ประมาณ 33 นาที) - chrony – Frequently Asked Questions chrony
แนะนำให้อนุญาต step เพียงไม่กี่ครั้งหลังเริ่มทำงาน เช่น makestep 1 3, VM ที่หยุดแล้วกลับมาทำงานอาจตื่นมาพร้อมเวลาที่คลาดเคลื่อน - clock_gettime(2) — Linux manual page Linux man-pages
CLOCK_MONOTONIC ไม่ได้รับผลจากการกระโดดแบบไม่ต่อเนื่องของนาฬิการะบบและไม่ถอยหลัง - chrony.conf(5) chrony
logchange: ถ้าปรับนาฬิกามากกว่าค่านี้ (ค่าเริ่มต้น 1 วินาที) จะบันทึกลง syslog
สาเหตุที่ควรดูประกอบ
ชั้นเดียวกัน: L7 OS ของเซิร์ฟเวอร์ (เคอร์เนล)
สาเหตุจากชั้นอื่นที่ทำให้เกิดอาการเดียวกัน (กรอเร็ว)
ดูการ์ดในฉบับหลักที่มีภาพและการทดลอง