Lichess Tablebase sunucusu optimizasyonu

Tablebase sunucusu optimizasyonu

Kuyruk gecikmesi sorununu çözme

• 7 taşlı Syzygy tablebase sunucusu, RAID bütünlük denetimi yürütülürken istekleri işlemekte zorlanıyordu
• Yeni yaklaşımla, veri blokları her okunduğunda manuel olarak doğrulama yapmak için dm-integrity LVM üzerinde kullanılacak şekilde değiştirildi
• 17 TiB'lik tablebase'i kesinti olmadan taşımak için ikinci bir sunucu kurularak benchmark testleri yapıldı

Yeni donanım yapılandırması

• 32 GiB RAM
• 2 x 201 GiB NVMe (önceki sunucuda SSD alanı yoktu)
• 6 x 5.46 TiB HDD (önceki sunucuda yalnızca 5 disk vardı)
• İşletim sistemi: Debian bookworm

İzlemenin önemi

• RAID 5 kullanılarak tek disk arızasından kurtarma sağlanıyor ve rastgele okumalar tüm disklere dağıtılıyor
• İlk testlerde performans iyi görünse de, izleme sayesinde tüm disklerin eşit biçimde devreye girmediği fark edildi

Benchmark sonuçları

• Sunucu saniyede 10 ila 35 istek alıyor
• 1 milyon istek kaydedilerek benchmark testleri yapıldı
• Ortalama yanıt süresi hızlı, ancak kuyruk gecikmesi yüksek
• pread, mmap'ten daha iyi performans gösterdi

mmap ve pread karşılaştırması

• mmap: Dosyayı belleğe eşleyerek disk okumalarını saydam biçimde işler, ancak hata yönetimi zordur
• pread: Okuma hatalarını sistem çağrısı üzerinden dönüş değeri olarak bildirir
• pread'in daha iyi performans göstermesinin nedeni, belleğe eşlenen veri bloklarının sayfa sınırlarını aştığında iki disk okumasına yol açabilmesidir

POSIX_FADV_RANDOM'ın ters etkisi

• POSIX_FADV_RANDOM, sayfa önbelleği baskısını azaltmak için işletim sistemine dosya erişiminin rastgele olduğuna dair ipucu verir, ancak pratikte ters etki yaratır
• Tablebase erişim örüntüsü aslında rastgele olmayabilir

Sınırlı SSD alanını kullanma

• SSD alanını verimli kullanmak için sparse block length list ve block length list SSD'de tutuldu; böylece en fazla 1 yavaş disk okuması garanti edildi
• RAID 1 yerine RAID 0 kullanılarak yedeklilikten vazgeçildi ve performans optimize edildi

Okumaları paralelleştirme

• Kullanıcı arayüzünde tüm hamlelerin DTZ değerlerini göstermek için ortalama bir istek 23 WDL probe ve 70 DTZ probe üretiyor
• İstek işlemeyi paralelleştirmek kuyruk gecikmesini azalttı

Gerçek ortam performansı

• Benchmark senaryosunda yapılan optimizasyonların gerçek ortamda da fayda sağladığı doğrulandı

# GN⁺ özeti

• Bu yazı, Lichess'in tablebase sunucusunu optimize etme sürecini ele alıyor
• Kuyruk gecikmesini azaltmak için çeşitli yaklaşımlar denendi ve benchmark testleriyle performans doğrulandı
• mmap ve pread karşılaştırması, POSIX_FADV_RANDOM'ın ters etkisi, SSD alanının kullanımı ve okuma paralelleştirmesi gibi konular işleniyor
• Yazı, sunucu optimizasyonuyla ilgilenen geliştiriciler için faydalı olabilir; benzer işlevlere sahip projeler arasında Stockfish de bulunuyor