Re: Lock contention high
От | Peter Geoghegan |
---|---|
Тема | Re: Lock contention high |
Дата | |
Msg-id | CAH2-Wzm059hvTLu0uRT-gENr-D2Uu70WbNL1-J=zEpFr1DCXoA@mail.gmail.com обсуждение исходный текст |
Ответ на | Lock contention high (Ashkil Dighin <ashkildighin76@gmail.com>) |
Ответы |
Re: Lock contention high
|
Список | pgsql-performance |
On Tue, Oct 12, 2021 at 12:45 AM Ashkil Dighin <ashkildighin76@gmail.com> 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
В списке pgsql-performance по дате отправления: