Optimización del servidor Tablebase de Lichess

Optimización del servidor tablebase

Resolución de la latencia de cola

• El servidor de tablebases Syzygy de 7 piezas tenía dificultades para procesar solicitudes mientras realizaba verificaciones de integridad RAID
• Con un nuevo enfoque, se cambió a usar dm-integrity sobre LVM para verificar manualmente cada vez que se leen bloques de datos
• Se configuró un segundo servidor para realizar pruebas de benchmark y migrar 17 TiB de tablebases sin tiempo de inactividad

Nueva configuración de hardware

• 32 GiB de RAM
• 2 x 201 GiB NVMe (el servidor anterior no tenía espacio SSD)
• 6 x 5.46 TiB HDD (el servidor anterior solo tenía 5 discos)
• Sistema operativo: Debian bookworm

La importancia del monitoreo

• Se usa RAID 5 para recuperarse de la falla de un solo disco y distribuir lecturas aleatorias entre todos los discos
• En las pruebas iniciales, el rendimiento parecía aceptable, pero el monitoreo reveló que no todos los discos participaban de forma uniforme

Resultados del benchmark

• El servidor recibe entre 10 y 35 solicitudes por segundo
• Se registraron 1 millón de solicitudes para realizar pruebas de benchmark
• El tiempo de respuesta promedio es rápido, pero la latencia de cola es alta
• pread mostró mejor rendimiento que mmap

Comparación entre mmap y pread

• mmap: mapea archivos en memoria y maneja las lecturas de disco de forma transparente, pero el manejo de errores es difícil
• pread: reporta errores de lectura mediante valores de retorno a través de llamadas al sistema
• pread muestra mejor rendimiento porque los bloques de datos mapeados en memoria pueden provocar dos lecturas de disco cuando cruzan límites de página

El efecto contraproducente de POSIX_FADV_RANDOM

• Usar POSIX_FADV_RANDOM le da al sistema operativo una pista de que el acceso al archivo es aleatorio para reducir la presión sobre la caché de páginas, pero en la práctica tuvo el efecto contrario
• Es posible que el patrón de acceso a las tablebases no sea realmente aleatorio

Aprovechamiento del espacio SSD limitado

• Para usar eficientemente el espacio SSD, se almacenan en SSD listas de longitudes de bloques dispersos y listas de longitudes de bloques para garantizar como máximo 1 lectura lenta de disco
• Se usó RAID 0 en lugar de RAID 1 para sacrificar redundancia y optimizar el rendimiento

Paralelización de lectura

• Para mostrar valores DTZ para todos los movimientos en la interfaz de usuario, una solicitud promedio genera 23 probes WDL y 70 probes DTZ
• La paralelización del procesamiento de solicitudes reduce la latencia de cola

Rendimiento en producción

• Se confirmó que las optimizaciones del escenario de benchmark también ayudan en el entorno real

# Resumen de GN⁺

• Este artículo trata sobre el proceso de optimización del servidor tablebase de Lichess
• Se experimentan varios enfoques para reducir la latencia de cola y se valida el rendimiento mediante pruebas de benchmark
• Se abordan temas como la comparación entre mmap y pread, el efecto contraproducente de POSIX_FADV_RANDOM, el aprovechamiento del espacio SSD y la paralelización de lectura
• Este artículo puede ser útil para desarrolladores interesados en la optimización de servidores, y proyectos con funciones similares incluyen Stockfish