Otimização do servidor de Tablebase do Lichess

Otimização do servidor de Tablebase

Resolvendo a latência de cauda

• O servidor de tablebase Syzygy de 7 peças teve dificuldade para processar requisições enquanto realizava a verificação de integridade do RAID
• A nova abordagem mudou para usar dm-integrity com LVM, fazendo a verificação manual sempre que um bloco de dados é lido
• Para migrar 17 TiB de tablebases sem downtime, foi configurado um segundo servidor para executar testes de benchmark

Nova configuração de hardware

• 32 GiB de RAM
• 2 x 201 GiB NVMe (o servidor anterior não tinha espaço em SSD)
• 6 x 5.46 TiB HDD (o servidor anterior tinha apenas 5 discos)
• Sistema operacional: Debian bookworm

A importância do monitoramento

• Usando RAID 5, é possível se recuperar da falha de um único disco e distribuir leituras aleatórias entre todos os discos
• Nos testes iniciais, o desempenho parecia bom, mas o monitoramento revelou que nem todos os discos estavam participando de forma equilibrada

Resultados do benchmark

• O servidor recebe de 10 a 35 requisições por segundo
• O teste de benchmark foi realizado registrando 1 milhão de requisições
• O tempo médio de resposta é rápido, mas a latência de cauda é alta
• pread apresentou desempenho melhor que mmap

Comparação entre mmap e pread

• mmap: mapeia o arquivo na memória e lida com leituras de disco de forma transparente, mas dificulta o tratamento de erros
• pread: reporta erros de leitura por meio do valor de retorno da chamada de sistema
• pread tem desempenho melhor porque blocos de dados mapeados em memória podem causar duas leituras de disco ao atravessar limites de página

O efeito reverso de POSIX_FADV_RANDOM

• Ao usar POSIX_FADV_RANDOM, o sistema operacional recebe a dica de que o acesso ao arquivo é aleatório para reduzir a pressão no page cache, mas na prática o efeito foi o oposto
• O padrão de acesso à tablebase pode não ser aleatório

Aproveitando o espaço limitado em SSD

• Para usar o espaço do SSD com eficiência, a lista de comprimentos de blocos esparsos e a lista de comprimentos de blocos foram armazenadas no SSD, garantindo no máximo 1 leitura lenta de disco
• Foi usado RAID 0 em vez de RAID 1, abrindo mão da redundância para otimizar o desempenho

Paralelização de leitura

• Para mostrar os valores DTZ de todos os lances na interface do usuário, uma requisição média gera 23 probes WDL e 70 probes DTZ
• A paralelização do processamento das requisições reduz a latência de cauda

Desempenho em ambiente real

• Foi confirmado que as otimizações do cenário de benchmark também ajudam em ambiente real

# Resumo do GN⁺

• Este texto aborda o processo de otimização do servidor de tablebase do Lichess
• Diversas abordagens para reduzir a latência de cauda foram testadas, e o desempenho foi validado com testes de benchmark
• O texto trata de temas como a comparação entre mmap e pread, o efeito reverso de POSIX_FADV_RANDOM, o aproveitamento do espaço em SSD e a paralelização de leitura
• O artigo pode ser útil para desenvolvedores interessados em otimização de servidores, e um projeto com funcionalidade semelhante é o Stockfish