io_uring에서 readahead를 제거하면 어떤 일이 벌어질까
Io_uring Without Readahead
Turso 데이터베이스의 io_uring 백엔드에서 readahead를 구현한 PR을 계기로, io_uring의 성능 특성을 분석한 글입니다. O_DIRECT로 파일을 열면 커널의 readahead가 비활성화되어 애플리케이션 수준에서 구현해야 합니다. readahead를 켜면 32개 페이지를 한 번에 제출하여 블록 레이어의 요청 병합이 활성화되고, 장치 요청 수가 약 196,000개에서 16,300개로 줄어듭니다. 또한 SQ polling 스레드가 CPU를 65%나 사용하는 문제를 발견하고, 일반 io_uring으로 전환했을 때 시스템 시간이 크게 줄어드는 것을 확인했습니다. O_DIRECT는 페이지 캐시 복사를 생략하지만 CPU 캐시 미스를 증가시켜 성능에 영향을 줍니다. 결론적으로, io_uring의 성능은 readahead, SQ polling, 배칭 등 여러 요소에 의해 결정되며, 각 모델의 비용을 이해하고 측정하는 것이 중요합니다.
O_DIRECT는 복사 단계를 생략하지만, 데이터는 결국 어떤 시점에 CPU에 도달해야 합니다. 버퍼링된 읽기에서는 복사 중에, O_DIRECT에서는 쿼리 중에 캐시 미스로 발생합니다.
HN 토론
37- ComputerGuru
흥미로운 글이지만, 좀 심장이 철렁 내려앉는 기분이 드네요. (TPC든 뭐든) 벤치마킹은 여기서 올바른 접근 방식을 결정하는 방법이 절대 아닙니다. 벤치마킹은 엄밀히 말해 데이터베이스(주로 RDBMS)가 구동 중인 전체 하드웨어를 사실상 '소유'하는 경우에만 사용해야 합니다. 임베디드 데이터베이스가 순수 CRUD 애플리케이션의 백엔드로 동작하고 서버 측 렌더링, 파싱, 검증 등을 거의 수행하지 않아 본질적으로 비동기 HTTP-to-SQLite 인터페이스에 가깝다면 그런 방식으로 사용될 수 있습니다. 하지만 임베디드 DB는 대개 여러 목적을 위해 사용되는 머신(반드시 서버일 필요도 없음)에 배포되어 사용될 가능성이 높으며, 머신이 사용 가능한 리소스의 한계 내에서 그리고 상대적인 측면에서도 최상의 성능을 내야 하므로, CPU나 메모리 사용 측면에서 성능을 희생하더라도 '가치'를 위해 절충을 해야 할 수밖에 없습니다.
이것은 벤치마킹에만 국한된 이야기가 아닙니다. 커널로부터 캐시의 소유권을 가져오는 *어떤* 경우든 반드시 고려해야 할 핵심 사항입니다. 커널은 스택 전체에서 전역 상태를 볼 수 있고 메모리 압박이 있을 때 메모리를 반환하여 모든 것이 서로 잘 어우러지도록 보장할 수 있는 유일한 존재이기 때문입니다. 데이터베이스나 메모리에만 국한된 것도 아닙니다. 예를 들어 FreeBSD는 ZFS가 커널과 분리된 자체 캐시를 가지고 있기 때문에 발생한 문제가 유난히 많았습니다(둘 사이의 통합이 훨씬 긴밀하고 다양한 메커니즘이 존재함에도 불구하고).
- marginalia_nu
사용자 공간에서 연속적인 readahead를 수행한다면, 왜 preadv를 사용하지 않나요? 다음 상주 페이지까지의 readahead로 제한되겠지만, 적어도 제가 Marginalia의 인덱스에서 실험한 결과에 따르면, 단일 preadv 호출로 전체 읽기를 수행할 수 있는 모든 경우에 preadv가 io_uring을 이깁니다.
- amluto
왜 syscall과 특히 O_DIRECT를 사용한 io_uring 사이에서 선택해야 하는지 궁금합니다. 제가 알기로 Turso는 SQLite와 같아서 여러 프로세스가 동일한 데이터베이스에 접근하는 것을 지원하며, 버퍼링이 일부 워크로드에서 큰 이점이 될 것이라고 예상합니다. direct 없이 io_uring을 사용하는 것의 문제점은 무엇인가요? RWF_DONTCACHE라는 중간 지점도 있습니다.
- ErroneousBosh
이게 제 피드에서 지나갈 때마다 매번 "Radiohead 없는 Io_uring"으로 읽혔습니다. 물론 그렇게 할 수도 있겠지만, 그게 무슨 의미가 있겠어요?
- weatherlite
Io_urine은 노란 스레드를 사용하나요?