mmapをio_uringに置き換えたら、Rustクエリエンジンが遅くなった
We Replaced MMAP with Io_uring in Our Rust Query Engine. It Got Slower
Convivaは毎日数兆イベントを分析するRustクエリエンジンで、mmapからio_uringへ移行した。mmapはページキャッシュのスラッシングとカーネルロック競合でp95が30秒から150秒超に悪化し、1ポッドが4ポッドより41%高速だった。io_uringはメジャーフォールトを35倍削減したが、マイナーフォールトが8倍に増え、クエリ時間は13.6秒から21.8秒に伸びた。
mmapのページキャッシュは暗黙の共有状態である。ホスト上のすべてのプロセスが1つのキャッシュ、1つのロック階層、1つの追い出しポリシーを共有する。
HNでの議論
22- jandrewrogers
ここでの問題は、パフォーマンスの文脈ではmmapとio_uringは根本的に異なるソフトウェアアーキテクチャを必要とするということだ。単純に交換すべきではない。
io_uringのようなAPIは、O_DIRECTと組み合わせることで、ワークロード固有のユーザースペーススケジューラを第一原理から設計できるようにする。スケジューリングをランタイムに委任しているなら、それらのAPIが提供するように設計されたパフォーマンス上の利点のほとんどを放棄していることになる。多くの場合、パフォーマンスは悪化する。対照的に、mmapは暗黙的にすべてのスケジューリング決定を委任し、委任が戦略である場合にはランタイムと比べて利点がある。
io_uringの利点は、独自のスケジューラを設計するというコミットメントなしには限定的だ。良い面としては、熟練したスケジューラ設計者はこれらのAPIを使うことで、mmapと比べてパフォーマンスを大幅に（整数倍）向上させることができる。アプリケーション固有のスケジューラの設計は容易ではなく、高度なスキルを要する取り組みだ。しかし、その報酬は現実のものだ。
io_uringをうまく使うには、それが何をなし得るかを示すために必要なソフトウェアアーキテクチャに完全にコミットする必要がある。
- laserbeam
ここでの本当の問題は、パート2（記事の最後にリンクされている）があり、そこでio_uring実装がmmapの2倍速くなることだ。つまり、パート1のためのクリックベイト的なタイトルで、パート2で解決される。
なので彼らは2つの記事を書き上げ、そのうちの1つはただのragebaitだ。しかもどちらもLLMが書いたように見える。もしかしたらクールなアドバイスがあるかもしれないし、ないかもしれない…でも、私が読んで楽しいと思う形式ではない。
- londons_explore
ソフトウェアエンジニアリングには次のようなパターンがある：
* プロジェクトが存在する
* 新しい従業員が効率改善のアイデアを思いつく
* 実装に何ヶ月も費やす。古いコードパスはレガシーになる。
* 新しいものには、構築中に追加機能がボルトで留められる。
* 新しいものの効率は元のものより悪いことが判明するが、今では新機能と「技術的負債の削減」が推進要因になる。
* 新しいものがローンチされ、古いものは非推奨になるが、何ヶ月もの作業に見合う実質的な利益はほとんどない。