淺談 MySQL / PostgreSQL 的 Double Buffering (續)
MySQL 與 PostgreSQL 處理自有 Buffer 的思路很不同。
MySQL/InnoDB 習慣自己掌握 Buffer,希望盡量用到 InnoDB Buffer Pool 而不是 OS Cache,所以支援 O_DIRECT。(MySQL 有點瘋狂到希望自己掌握核心事物,包括 thread 是自己的輕量級 lightware-threading)
PostgreSQL 則是傾向善用現有資源,例如作業系統的 OS Cache 已經夠好,所以直接取用。
對於 Double Buffering,不使用 O_DIRECT 的 MySQL/InnoDB 記憶體耗用通常較 PostgreSQL 高。但好處是,如果 InnoDB Buffer Pool cache miss,還有 OS Cache 當做 Second-level Cache。
反之,PostgreSQL 因為自身 MVCC 設計帶來的副作用,通常不建議 Shared Buffer 超過 8 GB (即使機器有 2 TB 的記憶體也一樣)。此時把記憶體留給 OS Cache 並善用,反而是較好的策略。而這限制反而使得 Double Buffering 問題沒有 MySQL 那般嚴重。但壞處是,Shared Buffer 可能經常 cache miss,需要頻繁的把 OS Cache 移進 Shared Buffer,開銷較大。
另外,太依賴 OS Cache 也有壞處。PostgreSQL 想解決 Linux 平台上 Double Buffering 的問題,卻始終遇到 Kernel Bug (對 PosygreSQL 團隊而言),導致 I/O 操作變多,效能不佳。
最後,Double Buffering 不只是 MySQL / PostgreSQL 會遇到的問題。