Rust 查詢引擎將 mmap 換成 io_uring，結果反而變慢：系統頁面快取爭用導致延遲劇增
為何重要
此案例揭示了在非隨機存取的資料庫場景中，沿用標準系統 I/O 機制（如 mmap）在容器化擴充套件時可能面臨資源共享失效的風險。事件確認了 io_uring 與 O_DIRECT 的價值，這可能會加速後端儲存層面對高效能、繞過頁面快取方案的採用。
繼 Conviva 釋出技術分析，指出雖然使用 mmap 讀取 Arrow IPC 檔案在低負載下簡便高效，但在生產環境高並發下，因系統頁面快取爭用導致 p95 延遲飆升至 150 秒以上。
- 在 192 核、750GB RAM 的環境中，單一 Pod 處理同樣查詢比 4 個 Pod 快 41%，證明多 Pod 競爭的是共享的 OS 頁面快取而非 CPU 資源。
- mmap 峰值吞吐量僅達 3.44 GB/s，約為同一硬體透過 fio 使用 io_uring 引擎所能達到上限 21 GB/s 的 16%。
- 團隊發現虛擬位址空間膨脹至 3 TB，並識別出昂貴的上下文切換與核心級 mmap 鎖競爭為主要瓶頸。