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  (Ashkil Dighin <ashkildighin76@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: MichaelDBA
Дата:
Сообщение: Re: Lock contention high
Следующее
От: Jeremy Schneider
Дата:
Сообщение: Re: Lock contention high