테이블베이스 서버 최적화
꼬리 지연 시간 해결
- 7개 조각 Syzygy 테이블베이스 서버가 RAID 무결성 검사를 수행하는 동안 요청을 처리하는 데 어려움을 겪음
- 새로운 접근 방식으로 dm-integrity를 LVM에 사용하여 데이터 블록을 읽을 때마다 수동으로 검사하도록 변경
- 17 TiB의 테이블베이스를 다운타임 없이 마이그레이션하기 위해 두 번째 서버를 설정하여 벤치마크 테스트를 수행함
새로운 하드웨어 구성
- 32 GiB RAM
- 2 x 201 GiB NVMe (이전 서버에는 SSD 공간이 없었음)
- 6 x 5.46 TiB HDD (이전 서버에는 5개의 디스크만 있었음)
- 운영 체제: Debian bookworm
모니터링의 중요성
- RAID 5를 사용하여 단일 디스크 장애에서 복구 가능하고 모든 디스크에 무작위 읽기를 분산함
- 초기 테스트에서 성능이 괜찮았지만 모든 디스크가 고르게 참여하지 않았음을 모니터링을 통해 발견함
벤치마크 결과
- 서버는 초당 10~35개의 요청을 받음
- 1백만 개의 요청을 기록하여 벤치마크 테스트를 수행함
- 평균 응답 시간은 빠르지만 꼬리 지연 시간이 높음
- mmap보다 pread가 더 나은 성능을 보임
mmap과 pread 비교
- mmap: 파일을 메모리에 매핑하여 디스크 읽기를 투명하게 처리하지만 오류 처리가 어려움
- pread: 시스템 호출을 통해 읽기 오류를 반환 값으로 보고함
- pread가 더 나은 성능을 보이는 이유는 메모리 매핑된 데이터 블록이 페이지 경계를 넘어갈 때 두 번의 디스크 읽기를 발생시킬 수 있기 때문임
POSIX_FADV_RANDOM의 역효과
- POSIX_FADV_RANDOM을 사용하면 페이지 캐시 압력을 줄이기 위해 파일 접근이 무작위임을 운영 체제에 힌트 주지만, 실제로는 역효과를 나타냄
- 테이블베이스 접근 패턴이 무작위가 아닐 수 있음
제한된 SSD 공간 활용
- SSD 공간을 효율적으로 사용하기 위해 희소 블록 길이 목록과 블록 길이 목록을 SSD에 저장하여 최대 1회의 느린 디스크 읽기를 보장함
- RAID 1 대신 RAID 0을 사용하여 중복성을 포기하고 성능을 최적화함
읽기 병렬화
- 사용자 인터페이스에서 모든 이동에 대한 DTZ 값을 표시하기 위해 평균 요청이 23개의 WDL 프로브와 70개의 DTZ 프로브를 발생시킴
- 요청 처리의 병렬화를 통해 꼬리 지연 시간을 줄임
실제 환경에서의 성능
- 벤치마크 시나리오에서의 최적화가 실제 환경에서도 도움이 됨을 확인함
# GN⁺의 정리
- 이 글은 Lichess의 테이블베이스 서버 최적화 과정을 다루고 있음
- 꼬리 지연 시간을 줄이기 위한 다양한 접근 방식을 실험하고 벤치마크 테스트를 통해 성능을 검증함
- mmap과 pread의 비교, POSIX_FADV_RANDOM의 역효과, SSD 공간 활용, 읽기 병렬화 등의 주제를 다룸
- 이 글은 서버 최적화에 관심 있는 개발자들에게 유용할 수 있으며, 비슷한 기능을 가진 프로젝트로는 Stockfish 등이 있음