Tablebase सर्वर ऑप्टिमाइज़ेशन
tail latency का समाधान
- 7-piece Syzygy tablebase सर्वर को RAID integrity check के दौरान requests संभालने में कठिनाई हो रही थी
- नए approach में dm-integrity को LVM पर इस्तेमाल करके data blocks को पढ़ते समय हर बार manually verify करने के लिए बदला गया
- 17 TiB tablebase को downtime के बिना migrate करने के लिए benchmark tests चलाने हेतु दूसरा सर्वर सेटअप किया गया
नया hardware configuration
- 32 GiB RAM
- 2 x 201 GiB NVMe (पिछले सर्वर में SSD space नहीं था)
- 6 x 5.46 TiB HDD (पिछले सर्वर में केवल 5 disks थीं)
- operating system: Debian bookworm
monitoring का महत्व
- RAID 5 का उपयोग करके single disk failure से recovery संभव हुई और random reads सभी disks में distribute किए गए
- शुरुआती tests में performance ठीक थी, लेकिन monitoring से पता चला कि सभी disks समान रूप से भाग नहीं ले रही थीं
benchmark परिणाम
- सर्वर को प्रति सेकंड 10 से 35 requests मिलती हैं
- 10 लाख requests रिकॉर्ड करके benchmark tests किए गए
- average response time तेज है, लेकिन tail latency अधिक है
mmap की तुलना में pread ने बेहतर performance दिखाई
mmap और pread की तुलना
mmap: file को memory में map करके disk reads को transparently handle करता है, लेकिन error handling कठिन होती हैpread: system call के जरिए read errors को return value के रूप में रिपोर्ट करता हैpread के बेहतर performance का कारण यह है कि memory-mapped data block page boundary पार करते समय दो बार disk read करा सकता है
POSIX_FADV_RANDOM का उल्टा असर
POSIX_FADV_RANDOM इस्तेमाल करने पर operating system को यह hint दिया जाता है कि file access random है ताकि page cache pressure कम हो, लेकिन वास्तव में इसका उल्टा असर दिखा- हो सकता है कि tablebase access pattern वास्तव में random न हो
सीमित SSD space का उपयोग
- SSD space का कुशल उपयोग करने के लिए sparse block length list और block length list को SSD पर रखा गया, ताकि अधिकतम 1 बार धीमी disk read की गारंटी हो
- RAID 1 की जगह RAID 0 का उपयोग करके redundancy छोड़ी गई और performance को optimize किया गया
read parallelization
- user interface में सभी moves के लिए DTZ values दिखाने हेतु एक average request में 23 WDL probes और 70 DTZ probes उत्पन्न होते हैं
- request processing के parallelization के जरिए tail latency कम की गई
वास्तविक environment में performance
- यह पुष्टि हुई कि benchmark scenario में की गई optimizations वास्तविक environment में भी मददगार हैं
# GN⁺ की संक्षिप्त प्रस्तुति
- यह लेख Lichess के tablebase सर्वर के optimization process पर केंद्रित है
- tail latency कम करने के लिए विभिन्न approaches आज़माए गए और benchmark tests के जरिए performance verify की गई
mmap और pread की तुलना, POSIX_FADV_RANDOM के उल्टे असर, SSD space उपयोग, और read parallelization जैसे विषय शामिल हैं- सर्वर optimization में रुचि रखने वाले developers के लिए यह लेख उपयोगी हो सकता है, और समान क्षमता वाले projects में Stockfish शामिल है
अभी कोई टिप्पणी नहीं है.