Comments on: Benchmark PostgreSQL With Linux HugePages

By: Maha

Maha — Wed, 15 Jul 2020 07:15:45 +0000

Thanks for the wonderful information and i learn so much from your post. i am student of MCS and now i am learning the HTML. All Linux SQL i have noted my note book.
Thanks for the information….

By: decanter2020

decanter2020 — Thu, 19 Dec 2019 08:11:12 +0000

You have shared such an amazing guide. I’m a big fan of using unique and popular typography fonts on my site. I have designed many popular mockups by using great fonts. Your sharing is really appreciated.

By: Ibrar Ahmed

Ibrar Ahmed — Thu, 10 Jan 2019 11:21:09 +0000

In reply to Максим Милютин. Yes, I am doing the benchmark with all the statistics, I will share the results with all statistics in my next blog.

By: Максим Милютин

Максим Милютин — Thu, 10 Jan 2019 11:02:04 +0000

+1 for pgbench params.

Along with this could you share for each test especially for cases under transition from 80GB to 96GB of db size:
– DB buffer hits and misses (differential value of blks_hit and blks_read columns from pg_stat_database)
– differential OS statistics from pg_stat_kcache (https://github.com/powa-team/pg_stat_kcache)
– TLB statistics from perf stat.

By: Peter Zaitsev

Peter Zaitsev — Sat, 05 Jan 2019 00:05:12 +0000

In reply to dharshanr. Hi, The database page size, which is also logical page size used for cache and the physical memory page size should not be related. Nothing prevents you from allocating using 1G pages and when doing 8K IO sizes into the allocated area

By: dharshanr

dharshanr — Sat, 29 Dec 2018 19:32:50 +0000

Thanks for putting this together. I would assume that performance gains here depend on the churn in the buffer pool. If there isn’t locality of reference in the workload I think large pages will do much worse than 4k since more data has to be moved in and out of the buffer.

By: Peter Zaitsev

Peter Zaitsev — Thu, 27 Dec 2018 15:12:46 +0000

In reply to Nils. Yeah. Benchmarks with NUMA it is all another story. I would imagine this would be interesting case of single instance vs multiple instances. In theory if you're using Sharding anyway (Citus or something else) having multiple PostgreSQL instances where each is locked to the given chip both in CPU cores and memory allocation can perform faster... but how much faster

By: Nils

Nils — Thu, 27 Dec 2018 15:02:13 +0000

Thank you for putting this together. Since you’e using a NUMA system it may be interesting to see how the memory is allocated among nodes. Given AMD Zen and Intel considering MCP for server chips this area of optimization is becoming increasingly important.

By: Peter Zaitsev

Peter Zaitsev — Thu, 27 Dec 2018 14:38:19 +0000

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.

By: chAlx

chAlx — Mon, 24 Dec 2018 10:12:31 +0000

How to reproduce these testcases? Pgbench params etc.

PS: autovacuum_vacuum_scale_factor = ‘0.4’ is not suitable for heavy OLTP load.