| From: | Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Improving connection scalability: GetSnapshotData() |
| Date: | 2020-09-06 11:05:35 |
| Message-ID: | 48a3de99-bcea-c68e-8078-3ead2e01d878@postgrespro.ru |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 04.09.2020 21:53, Andres Freund wrote:
>
>> May be it is because of more complex architecture of my server?
> Think we'll need profiles to know...
This is "perf top" of pgebch -c 100 -j 100 -M prepared -S
12.16% postgres [.] PinBuffer
11.92% postgres [.] LWLockAttemptLock
6.46% postgres [.] UnpinBuffer.constprop.11
6.03% postgres [.] LWLockRelease
3.14% postgres [.] BufferGetBlockNumber
3.04% postgres [.] ReadBuffer_common
2.13% [kernel] [k] _raw_spin_lock_irqsave
2.11% [kernel] [k] switch_mm_irqs_off
1.95% postgres [.] _bt_compare
Looks like most of the time is pent in buffers locks.
And which pgbench database scale factor you have used?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2020-09-06 11:37:40 | Re: Optimising compactify_tuples() |
| Previous Message | Michael Paquier | 2020-09-06 03:04:26 | Re: Range checks of pg_test_fsync --secs-per-test and pg_test_timing --duration |