| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Justin Lu <justin(dot)lu5432(at)gmail(dot)com> |
| Cc: | pgsql-admin(at)lists(dot)postgresql(dot)org, pgsql-admin(at)postgresql(dot)org |
| Subject: | Re: Heavy LWLockTranche buffer_mapping in Postgres 9.6.10 server |
| Date: | 2020-02-02 15:15:03 |
| Message-ID: | 20200202151503.yvny5akgkimquqz6@alap3.anarazel.de |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
Hi,
On 2020-02-01 16:17:13 -0700, Justin Lu wrote:
> We are seeing very heavy LWLockTranche buffer_mapping in db recently.
>
> There server had 24 core, 128GB of RAM, SSD data file system, on Unbuntu
> 16.04.6.
> The shared_buffers was at 32GB. 1/4 of over RAM size. No issue on
> checkpoints (avg time 29 min apart).
>
> After seeing the heavy wait, we added 64GB more RAM and increased
> shared_buffers to 48GB, effective_cache_size to 90GB. But it seems there is
> no impact on the buffer mapping waits at all.
I suggest doing a perf profile with --call-graph dwarf, to see where
this is mostly coming from.
One thing I've seen causing symptoms like this before, is if there's
suddenly a larger amount of table truncations, dropping, etc - dropping
/ truncating a table / index needs to scan all of shared buffers...
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Justin Lu | 2020-02-03 19:30:55 | Re: Heavy LWLockTranche buffer_mapping in Postgres 9.6.10 server |
| Previous Message | Purav Chovatia | 2020-02-02 09:24:07 | Re: Heavy LWLockTranche buffer_mapping in Postgres 9.6.10 server |