|From:||Andrey Borodin <x4mmm(at)yandex-team(dot)ru>|
|To:||Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>|
|Cc:||Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>, Daniel Gustafsson <daniel(at)yesql(dot)se>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: MultiXact\SLRU buffers configuration|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
> 10 нояб. 2020 г., в 23:07, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> написал(а):
> On 11/10/20 7:16 AM, Andrey Borodin wrote:
>> but this picture was not stable.
> Seems we haven't made much progress in reproducing the issue :-( I guess
> we'll need to know more about the machine where this happens. Is there
> anything special about the hardware/config? Are you monitoring size of
> the pg_multixact directory?
It's Ubuntu 18.04.4 LTS, Intel Xeon E5-2660 v4, 56 CPU cores with 256Gb of RAM.
PostgreSQL 10.14, compiled by gcc 7.5.0, 64-bit
No, unfortunately we do not have signals for SLRU sizes.
3.5Tb mdadm raid10 over 28 SSD drives, 82% full.
First incident triggering investigation was on 2020-04-19, at that time cluster was running on PG 10.11. But I think it was happening before.
I'd say nothing special...
>> How do you collect wait events for aggregation? just insert into some table with cron?
> No, I have a simple shell script (attached) sampling data from
> pg_stat_activity regularly. Then I load it into a table and aggregate to
> get a summary.
Best regards, Andrey Borodin.
|Next Message||Daniel Gustafsson||2020-11-13 12:14:58||Re: Support for NSS as a libpq TLS backend|
|Previous Message||Pavel Borisov||2020-11-13 11:47:59||Re: [PATCH] Combine same ternary types in GIN and TSearch|