Re: MultiXact\SLRU buffers configuration
От | Andrey Borodin |
---|---|
Тема | Re: MultiXact\SLRU buffers configuration |
Дата | |
Msg-id | 13F86913-C01B-4983-AE2E-493F5A028280@yandex-team.ru обсуждение исходный текст |
Ответ на | Re: MultiXact\SLRU buffers configuration (Tomas Vondra <tomas.vondra@enterprisedb.com>) |
Ответы |
Re: MultiXact\SLRU buffers configuration
|
Список | pgsql-hackers |
> 10 нояб. 2020 г., в 23:07, Tomas Vondra <tomas.vondra@enterprisedb.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 washappening 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. Thanks! Best regards, Andrey Borodin.
В списке pgsql-hackers по дате отправления: