Optimierung des Tablebase-Servers
Lösung der Tail-Latency-Probleme
- Der 7-Steine-Syzygy-Tablebase-Server hatte Schwierigkeiten, Anfragen zu verarbeiten, während RAID-Integritätsprüfungen liefen
- Mit einem neuen Ansatz wurde auf
dm-integrity in LVM umgestellt, sodass Datenblöcke nun beim Lesen jeweils manuell geprüft werden
- Um 17 TiB Tablebases ohne Downtime zu migrieren, wurde ein zweiter Server für Benchmark-Tests eingerichtet
Neue Hardware-Konfiguration
- 32 GiB RAM
- 2 x 201 GiB NVMe (der vorherige Server hatte keinen SSD-Speicher)
- 6 x 5.46 TiB HDD (der vorherige Server hatte nur 5 Festplatten)
- Betriebssystem: Debian bookworm
Die Bedeutung von Monitoring
- Mit RAID 5 ist eine Wiederherstellung nach dem Ausfall einer einzelnen Festplatte möglich, außerdem werden zufällige Lesezugriffe auf alle Festplatten verteilt
- Erste Tests zeigten brauchbare Leistung, aber erst durch Monitoring wurde erkannt, dass nicht alle Festplatten gleichmäßig beteiligt waren
Benchmark-Ergebnisse
- Der Server erhält 10 bis 35 Anfragen pro Sekunde
- Für den Benchmark wurden 1 Million Anfragen aufgezeichnet
- Die durchschnittliche Antwortzeit ist schnell, aber die Tail-Latency ist hoch
pread zeigt bessere Leistung als mmap
Vergleich von mmap und pread
mmap: bildet Dateien in den Speicher ab und behandelt Festplattenzugriffe transparent, macht aber die Fehlerbehandlung schwierigpread: meldet Lesefehler über Rückgabewerte von Systemaufrufenpread ist vermutlich schneller, weil speicherabgebildete Datenblöcke beim Überschreiten von Seitengrenzen zwei Festplattenlesevorgänge auslösen können
Der kontraproduktive Effekt von POSIX_FADV_RANDOM
POSIX_FADV_RANDOM gibt dem Betriebssystem den Hinweis, dass Dateizugriffe zufällig sind, um den Druck auf den Page-Cache zu verringern, zeigte in der Praxis jedoch den gegenteiligen Effekt- Das Zugriffsmuster auf die Tablebases ist möglicherweise nicht wirklich zufällig
Nutzung des begrenzten SSD-Speichers
- Um den SSD-Speicher effizient zu nutzen, werden Sparse-Block-Längenlisten und Block-Längenlisten auf der SSD gespeichert, sodass höchstens ein langsamer Festplattenlesevorgang garantiert ist
- Statt RAID 1 wird RAID 0 verwendet, um auf Redundanz zu verzichten und die Leistung zu optimieren
Parallelisierung von Lesezugriffen
- Um in der Benutzeroberfläche DTZ-Werte für alle Züge anzuzeigen, erzeugt eine durchschnittliche Anfrage 23 WDL-Probes und 70 DTZ-Probes
- Durch Parallelisierung der Anfrageverarbeitung wird die Tail-Latency reduziert
Leistung in der Praxis
- Es wurde bestätigt, dass die Optimierungen aus dem Benchmark-Szenario auch in der realen Umgebung helfen
# Zusammenfassung von GN⁺
- Dieser Artikel beschreibt den Prozess zur Optimierung des Tablebase-Servers von Lichess
- Es werden verschiedene Ansätze zur Reduzierung der Tail-Latency erprobt und per Benchmark auf ihre Leistung überprüft
- Behandelt werden unter anderem der Vergleich von
mmap und pread, die negativen Effekte von POSIX_FADV_RANDOM, die Nutzung von SSD-Speicher und die Parallelisierung von Lesezugriffen
- Der Artikel kann für Entwickler nützlich sein, die sich für Server-Optimierung interessieren; ein ähnliches Projekt ist etwa Stockfish
Noch keine Kommentare.