On Tue, Oct 12, 2021 at 12:45 AM Ashkil Dighin <ashkildighin76@xxxxxxxxx> wrote: > Lock contention observed high in PostgreSQLv13.3 > The source code compiled with GNC(GCCv11.x) > PostgreSQL version: 13.3 > Operating system: RHEL8.3 > Kernel name:4.18.0-305.10.2.el8_4.x86_64 > RAM Size:512GB > SSD: 1TB > The environment used IBM metal and test benchmark environment HammerDbv4.2 > Test case :TPC-C You didn't say how many TPC-C warehouses you used. In my experience, people sometimes run TPC-C with relatively few, which will tend to result in extreme contention on certain B-Tree leaf pages. (My experiences are with BenchmarkSQL, but I can't imagine HammerDB is too much different.) Assuming that's the case here, for you, then it's not clear that you have a real problem. You're really not supposed to run the benchmark in that way, per the TPC-C spec, which strictly limits the number of transactions per minute per warehouse -- for better or worse, valid results generally require that you use lots of warehouses to get a very large database (think terabytes). If you run the benchmark with 100 warehouses or less, on a big server, then the contention you'll see will be out of all proportion to what you're ever likely to see in the real world. -- Peter Geoghegan
