การปรับแต่งเซิร์ฟเวอร์ Tablebase
การแก้ปัญหา tail latency
- เซิร์ฟเวอร์ Syzygy tablebase แบบ 7 ตัวหมากมีปัญหาในการรองรับคำขอระหว่างที่ทำการตรวจสอบความถูกต้องของ RAID
- เปลี่ยนไปใช้แนวทางใหม่โดยใช้ dm-integrity กับ LVM เพื่อให้ตรวจสอบแบบแมนนวลทุกครั้งที่อ่านบล็อกข้อมูล
- ตั้งค่าเซิร์ฟเวอร์เครื่องที่สองเพื่อทดสอบ benchmark สำหรับการย้าย tablebase ขนาด 17 TiB โดยไม่มี downtime
ฮาร์ดแวร์คอนฟิกใหม่
- RAM 32 GiB
- 2 x 201 GiB NVMe (เซิร์ฟเวอร์เดิมไม่มีพื้นที่ SSD)
- 6 x 5.46 TiB HDD (เซิร์ฟเวอร์เดิมมีดิสก์เพียง 5 ลูก)
- ระบบปฏิบัติการ: Debian bookworm
ความสำคัญของการมอนิเตอร์
- ใช้ RAID 5 เพื่อกู้คืนได้เมื่อดิสก์เสีย 1 ลูก และกระจายการอ่านแบบสุ่มไปยังดิสก์ทุกลูก
- การทดสอบเบื้องต้นดูเหมือนประสิทธิภาพใช้ได้ แต่พบจากการมอนิเตอร์ว่าดิสก์ไม่ได้ทำงานอย่างสม่ำเสมอเท่ากันทุกลูก
ผลลัพธ์ benchmark
- เซิร์ฟเวอร์ได้รับคำขอ 10~35 รายการต่อวินาที
- ทำการทดสอบ benchmark โดยบันทึกคำขอจำนวน 1 ล้านรายการ
- เวลาในการตอบสนองเฉลี่ยรวดเร็ว แต่ tail latency สูง
pread ให้ประสิทธิภาพดีกว่า mmap
เปรียบเทียบ mmap กับ pread
mmap: แมปไฟล์เข้ากับหน่วยความจำเพื่อจัดการการอ่านดิสก์แบบโปร่งใส แต่จัดการข้อผิดพลาดได้ยากpread: รายงานข้อผิดพลาดการอ่านผ่านค่าที่ส่งกลับจาก system call- เหตุผลที่
pread ทำได้ดีกว่าอาจเป็นเพราะบล็อกข้อมูลที่แมปกับหน่วยความจำอาจข้ามขอบเขตของ page และทำให้เกิดการอ่านดิสก์ 2 ครั้ง
ผลเสียย้อนกลับของ POSIX_FADV_RANDOM
- การใช้
POSIX_FADV_RANDOM เป็นการส่ง hint ให้ระบบปฏิบัติการทราบว่าการเข้าถึงไฟล์เป็นแบบสุ่มเพื่อลดแรงกดดันต่อ page cache แต่ในทางปฏิบัติกลับให้ผลตรงกันข้าม
- รูปแบบการเข้าถึง tablebase อาจไม่ได้เป็นแบบสุ่มจริง
การใช้พื้นที่ SSD ที่มีจำกัด
- เพื่อใช้พื้นที่ SSD ให้คุ้มค่า จึงเก็บ sparse block length list และ block length list ไว้บน SSD เพื่อรับประกันว่าจะมีการอ่านจากดิสก์ช้าอย่างมากไม่เกิน 1 ครั้ง
- ใช้ RAID 0 แทน RAID 1 โดยยอมสละความซ้ำซ้อนเพื่อปรับประสิทธิภาพให้เหมาะสมที่สุด
การทำให้การอ่านขนานกัน
- เพื่อให้ส่วนติดต่อผู้ใช้แสดงค่า DTZ สำหรับทุกการเดิน ค่าเฉลี่ยของคำขอหนึ่งครั้งจะก่อให้เกิด WDL probe 23 ครั้งและ DTZ probe 70 ครั้ง
- ลด tail latency ได้ด้วยการทำคำขอแบบขนาน
ประสิทธิภาพในสภาพแวดล้อมจริง
- ยืนยันได้ว่าการปรับแต่งในสถานการณ์ benchmark ช่วยได้จริงในสภาพแวดล้อมการใช้งานจริง
# สรุปโดย GN⁺
- บทความนี้กล่าวถึงกระบวนการปรับแต่งเซิร์ฟเวอร์ tablebase ของ Lichess
- มีการทดลองหลายแนวทางเพื่อลด tail latency และตรวจสอบประสิทธิภาพด้วยการทดสอบ benchmark
- ครอบคลุมหัวข้ออย่างการเปรียบเทียบ
mmap กับ pread, ผลเสียย้อนกลับของ POSIX_FADV_RANDOM, การใช้พื้นที่ SSD และการทำให้การอ่านขนานกัน
- บทความนี้อาจเป็นประโยชน์สำหรับนักพัฒนาที่สนใจการปรับแต่งเซิร์ฟเวอร์ และมีโครงการที่มีความสามารถคล้ายกัน เช่น Stockfish
ยังไม่มีความคิดเห็น