Re: Better way of dealing with pgstat wait timeout during buildfarm runs?
От | Michael Paquier |
---|---|
Тема | Re: Better way of dealing with pgstat wait timeout during buildfarm runs? |
Дата | |
Msg-id | CAB7nPqTQMRA8A8PJxDbnR4ditLtnkGfJrrQzvhcPAfdapkR7fg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Better way of dealing with pgstat wait timeout during buildfarm runs? (Tomas Vondra <tv@fuzzy.cz>) |
Список | pgsql-hackers |
On Fri, Dec 26, 2014 at 6:28 AM, Tomas Vondra <tv@fuzzy.cz> wrote: > On 25.12.2014 21:14, Andres Freund wrote: >> On 2014-12-25 14:36:42 -0500, Tom Lane wrote: >> >> My guess is that a checkpoint happened at that time. Maybe it'd be a >> good idea to make pg_regress start postgres with log_checkpoints >> enabled? My guess is that we'd find horrendous 'sync' times. >> >> Michael: Could you perhaps turn log_checkpoints on in the config? > > Logging timestamps (using log_line_prefux) would be also helpful. Done. If have been wondering about those failures as well but didn't get the time to look around. FYI, hamster is running with a 8GB class 10 SD card able to do 40M/s in read, card that I changed 2 weeks ago btw, the former 4GB card beginning to show I/O errors, RIP to it. So this is what is triggering the wait timeouts more frequently... But I have no real explanation why REL9_4_STABLE shows no signs of failures. For the time being, what about putting pg_stats_tmp into a ram disk to leverage the I/O? Whatever what we come up with, I imagine that I/O will still be tight on hamster. -- Michael
В списке pgsql-hackers по дате отправления: