From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Paul Friedman <paul(dot)friedman(at)streetlightdata(dot)com> |
Cc: | pgsql-performance(at)lists(dot)postgresql(dot)org |
Subject: | Re: LWLocks by LockManager slowing large DB |
Date: | 2021-04-12 21:57:38 |
Message-ID: | 20210412215738.xytq33wlciljyva5@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Hi,
On 2021-04-12 12:37:42 -0700, Paul Friedman wrote:
> Boiling the complex queries down to their simplest form, we test running 60
> of this query simultaneously:
How long does one execution of these queries take (on average)? The
likely bottlenecks are very different between running 60 concurrent
queries that each complete in 0.1ms and ones that take > 1s.
Could you show the results for a query like
SELECT state, backend_type, wait_event_type, wait_event, count(*) FROM pg_stat_activity GROUP BY 1, 2, 3, 4 ORDER BY count(*) DESC;
?
Without knowing the proportion of LockManager wait events compared to
the rest it's hard to know what to make of it.
> Does anyone have any advice on how to alleviate LockManager’s LWlock issue?
It'd be useful to get a perf profile for this. Both for cpu time and for
what ends up blocking on kernel-level locks. E.g. something like
# cpu time
perf record --call-graph dwarf -F 500 -a sleep 5
perf report --no-children --sort comm,symbol
To send it to the list you can use something like
perf report --no-children --sort comm,symbol|head -n 500 > somefile
# kernel level blocking on locks
perf record --call-graph dwarf -e syscalls:sys_enter_futex -a sleep 3
perf report --no-children --sort comm,symbol
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Paul Friedman | 2021-04-12 22:15:05 | RE: LWLocks by LockManager slowing large DB |
Previous Message | Paul Friedman | 2021-04-12 19:37:42 | LWLocks by LockManager slowing large DB |