Optimasi server tablebase Lichess

Optimasi server tablebase

Mengatasi tail latency

• Server tablebase Syzygy 7-buah kesulitan menangani permintaan saat melakukan pemeriksaan integritas RAID
• Pendekatan baru mengubah penggunaan dm-integrity pada LVM agar pemeriksaan dilakukan secara manual setiap kali blok data dibaca
• Server kedua disiapkan untuk menjalankan pengujian benchmark guna memigrasikan tablebase 17 TiB tanpa downtime

Konfigurasi hardware baru

• 32 GiB RAM
• 2 x 201 GiB NVMe (server sebelumnya tidak memiliki ruang SSD)
• 6 x 5.46 TiB HDD (server sebelumnya hanya memiliki 5 disk)
• Sistem operasi: Debian bookworm

Pentingnya monitoring

• Menggunakan RAID 5 agar bisa pulih dari kegagalan satu disk dan mendistribusikan pembacaan acak ke semua disk
• Pada pengujian awal performanya tampak baik, tetapi melalui monitoring ditemukan bahwa tidak semua disk berpartisipasi secara merata

Hasil benchmark

• Server menerima 10~35 permintaan per detik
• Pengujian benchmark dilakukan dengan merekam 1 juta permintaan
• Waktu respons rata-rata cepat, tetapi tail latency tinggi
• pread menunjukkan performa yang lebih baik daripada mmap

Perbandingan mmap dan pread

• mmap: memetakan file ke memori dan menangani pembacaan disk secara transparan, tetapi penanganan error sulit
• pread: melaporkan error pembacaan melalui system call sebagai nilai balik
• pread menunjukkan performa lebih baik karena blok data yang dipetakan ke memori dapat memicu dua kali pembacaan disk saat melintasi batas halaman

Efek negatif POSIX_FADV_RANDOM

• POSIX_FADV_RANDOM memberi petunjuk ke sistem operasi bahwa akses file bersifat acak untuk mengurangi tekanan page cache, tetapi dalam praktiknya justru berdampak sebaliknya
• Pola akses tablebase mungkin sebenarnya tidak acak

Memanfaatkan ruang SSD yang terbatas

• Untuk menggunakan ruang SSD secara efisien, daftar panjang blok sparse dan daftar panjang blok disimpan di SSD guna menjamin maksimal 1 kali pembacaan disk lambat
• RAID 0 digunakan alih-alih RAID 1 untuk mengorbankan redundansi dan mengoptimalkan performa

Paralelisasi pembacaan

• Untuk menampilkan nilai DTZ untuk semua langkah di antarmuka pengguna, rata-rata satu permintaan memicu 23 probe WDL dan 70 probe DTZ
• Paralelisasi penanganan permintaan mengurangi tail latency

Performa di lingkungan nyata

• Dipastikan bahwa optimasi dalam skenario benchmark juga membantu di lingkungan nyata

# Ringkasan GN⁺

• Artikel ini membahas proses optimasi server tablebase milik Lichess
• Berbagai pendekatan untuk mengurangi tail latency diuji dan performanya divalidasi melalui benchmark
• Topik yang dibahas mencakup perbandingan mmap dan pread, efek negatif POSIX_FADV_RANDOM, pemanfaatan ruang SSD, dan paralelisasi pembacaan
• Artikel ini dapat berguna bagi developer yang tertarik pada optimasi server, dan proyek dengan fungsi serupa antara lain Stockfish