Percona 對於 PostgreSQL 使用 HugePages 的評論

摘要： 開頭我先說一下我的想法，我對於Percona 的 Ibrar Ahmed 的文章保持著懷疑的態度，因為他先前在「Benchmark PostgreSQL With Linux HugePages 」這篇做的 benchmark 就有奇怪的結果，但卻給不出合理的原因，甚至連 P...

開頭我先說一下我的想法，我對於Percona 的 Ibrar Ahmed 的文章保持著懷疑的態度，因為他先前在「Benchmark PostgreSQL With Linux HugePages 」這篇做的 benchmark 就有奇怪的結果，但卻給不出合理的原因，甚至連 Percona 自家的 CEO 公開在 comment 問之後也沒有看到文章提出合理的解釋：

Hi,
A lot of interesting results here…
1) PgBench access distribution is very interesting. With database size growing by 20% from 80G to 96G we see performance drop of Several times which is very counter-intuitive
2) There is no difference between 2MB and 4K but huge difference between 1G and 2M even though I would expect at least some TLB miss reduction in the first transitioning. I would understand it in case transparent huge pages are Enabled… but not disabled
3) For 96GB why would throughput grow with number of clients for 1G but fall for 2M and 4KB.

這次看到「Settling the Myth of Transparent HugePages for Databases 」這篇，也是在討論Linux 的 HugePages 對PostgreSQL 帶來的影響，同樣馬上又看到奇怪的東西...

首先是標示與圖片不合：

Figure 1.1 PostgreSQL’ s Benchmark, 10 minutes execution time where database workload(48GB) < shared_buffer (64GB)

Figure 1.2 PostgreSQL’ s Benchmark, 10 minutes execution time where database workload (48GB) > shared_buffer (64GB)

不過這邊可以推測 Figure 1.2 應該是 112GB (因為對應的圖片上面標的是 112GB)，當做是標錯就好。

但這樣又跑出一個奇怪的結果，48GB 的資料量比較小，TPS 大約是 35K/33K/41K，但 112GB 資料量比較大，卻可以達到 39K/43K/41K~42K，反而比較快？我暫時想不到什麼理由...

整體的測試有 pgbench 與 sysbench (這邊也打錯成 sysbecnch，先不管)，其中 pgbench 跑了 10 mins 與 60 mins 的版本，但是 sysbench 只跑了 10 mins 的版本？這是什麼原因...

另外還是有些情況是開啟 HugePages 比較快的 (sysbench 的 64 clients)，如果以直覺來說的話，我反而還是會開啟 HugePages (yeah 純粹是直覺)，我現在比較想知道他會在 Percona 裡面待多久...