Grafana Labs에서 Mimir의 성능을 개선한 얘기입니다. Prometheus는 하나의 서버에서 매트릭을 저장하기 때문에 매트릭이 많아지면 감당하기 어려워지므로 일정 기간내의 매트릭만 저장하

Grafana Labs에서 Mimir의 성능을 개선한 얘기입니다. Prometheus는 하나의 서버에서 매트릭을 저장하기 때문에 매트릭이 많아지면 감당하기 어려워지므로 일정 기간내의 매트릭만 저장하기게 되는데 이 Prometheus의 데이터를 오래 보관할 수 있는 장기 스토리지로 보통 Cortex를 사용합니다. Grafana Labs도 Cortex에 기여하고 있었지만 작년부터 Cortex를 포크해서 Mimir란 프로젝트를 별도로 관리하고 있고 이는 Cortex와 같은 목적의 Prometheus 장기 스토리지입니다. 이 Mimir의 쿼리 속도를 개선한 얘기입니다. Mimir도 Prometheus TSDB 형식을 사용하고 있지만 장기 스토리지이므로 단인 노드가 아닌 S3나 GCS에 저장할 수 있도록 설계되었습니다. Prometheus TSDB의 블록 인덱스의 서브셋인 index-header를 사용해서 store-gateway가 쿼리와 일치하는 블록이 어디에 있는지에 대한 정보를 제공합니다. 단일 노드에서는 노드 내에서 쿼리하면 되지만 장기 스토리지에서는 그럴수가 없으므로 index-header와 store-gateway를 사용하는 것입니다. 기존에 파일을 메모리처럼 호출할 수 있는 mmap을 사용하고 있었는데 성능 문제를 발편해서 살펴보다보니 Go 언어의 고루틴에서 mmap을 사용할 셩우 고루틴 자체가 브로킹되어 속도가 느려지는 것을 알게 되었고 이를 일반 파일 I/O로 바꾸기로 결정했다고 합니다. 일반 파일 I/O로 그냥 바꾸어서는 성능이 나오지 않으므로 Berffered I/o를 사용하고 index-header를 위한 파일 핸들 풀을 사용하고 레이블에 대한 문자열도 별도로 생성 안하게 작업하면서 성능을 개선했다고 합니다. https://grafana.com/blog/2023/07/17/improving-query-performance-in-grafana-mimir-why-we-dropped-mmap-from-the-store-gateway/