Optimisation du serveur de tablebase de Lichess

Optimisation du serveur de tablebase

Résolution de la latence en queue

• Le serveur de tablebase Syzygy à 7 pièces avait du mal à traiter les requêtes pendant les vérifications d’intégrité RAID
• Une nouvelle approche a remplacé cela par l’utilisation de dm-integrity avec LVM afin d’effectuer une vérification manuelle à chaque lecture de bloc de données
• Un second serveur a été mis en place pour effectuer des tests de benchmark afin de migrer 17 TiB de tablebases sans interruption de service

Nouvelle configuration matérielle

• 32 GiB de RAM
• 2 x 201 GiB NVMe (l’ancien serveur n’avait pas d’espace SSD)
• 6 x 5.46 TiB HDD (l’ancien serveur n’avait que 5 disques)
• Système d’exploitation : Debian bookworm

Importance du monitoring

• Utilisation de RAID 5 pour permettre la récupération après la panne d’un seul disque et répartir les lectures aléatoires sur tous les disques
• Les tests initiaux montraient des performances correctes, mais le monitoring a révélé que tous les disques ne participaient pas de manière homogène

Résultats du benchmark

• Le serveur reçoit entre 10 et 35 requêtes par seconde
• Un benchmark a été réalisé en enregistrant 1 million de requêtes
• Le temps de réponse moyen est rapide, mais la latence en queue est élevée
• pread montre de meilleures performances que mmap

Comparaison entre mmap et pread

• mmap : mappe les fichiers en mémoire et gère de façon transparente les lectures disque, mais la gestion des erreurs est difficile
• pread : signale les erreurs de lecture via la valeur de retour d’un appel système
• pread offre de meilleures performances, car des blocs de données mappés en mémoire peuvent entraîner deux lectures disque lorsqu’ils franchissent une limite de page

Effet contre-productif de POSIX_FADV_RANDOM

• L’utilisation de POSIX_FADV_RANDOM indique au système d’exploitation que l’accès au fichier est aléatoire afin de réduire la pression sur le cache de pages, mais cela a en réalité un effet inverse
• Le modèle d’accès aux tablebases n’est peut-être pas aléatoire

Exploitation d’un espace SSD limité

• Pour utiliser efficacement l’espace SSD, des listes de longueurs de blocs clairsemés et des listes de longueurs de blocs sont stockées sur SSD afin de garantir au maximum une seule lecture lente sur disque
• RAID 0 a été utilisé à la place de RAID 1, en sacrifiant la redondance pour optimiser les performances

Parallélisation des lectures

• Pour afficher les valeurs DTZ de tous les coups dans l’interface utilisateur, une requête moyenne déclenche 23 sondes WDL et 70 sondes DTZ
• La parallélisation du traitement des requêtes réduit la latence en queue

Performances en conditions réelles

• Il a été confirmé que les optimisations du scénario de benchmark aident aussi en environnement réel

# Le résumé de GN⁺

• Cet article traite du processus d’optimisation du serveur de tablebase de Lichess
• Différentes approches pour réduire la latence en queue ont été testées, et les performances ont été validées par benchmark
• Le texte aborde notamment la comparaison entre mmap et pread, l’effet contre-productif de POSIX_FADV_RANDOM, l’utilisation de l’espace SSD et la parallélisation des lectures
• Cet article peut être utile aux développeurs intéressés par l’optimisation serveur, et Stockfish est un projet aux fonctionnalités similaires