From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
Cc: | PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: postgresql latency & bgwriter not doing its job |
Date: | 2014-08-31 06:44:01 |
Message-ID: | alpine.DEB.2.10.1408310826420.14824@sto |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello Heikki,
> For the kicks, I wrote a quick & dirty patch for interleaving the fsyncs, see
> attached. It works by repeatedly scanning the buffer pool, writing buffers
> belonging to a single relation segment at a time.
I tried this patch on the same host I used with the same "-R 25 -L 200 -T
5000", alas without significant positive effects, about 6% of transactions
were "lost", including stretches of several seconds of unresponsiveness.
Maybe this is because "pgbench -N" only basically touches 2 tables
(accounts & history), so there are few file syncs involved, thus it does
not help much with spreading a lot of writes.
2014-08-30 23:52:24.167 CEST:
LOG: checkpoint starting: xlog
2014-08-30 23:54:09.239 CEST:
LOG: checkpoint sync: number=1 file=base/16384/11902 time=24.529 msec
2014-08-30 23:54:23.812 CEST:
LOG: checkpoint sync: number=1 file=base/16384/16397_vm time=32.547 msec
2014-08-30 23:54:24.771 CEST:
LOG: checkpoint sync: number=1 file=base/16384/11873 time=557.470 msec
2014-08-30 23:54:37.419 CEST:
LOG: checkpoint complete: wrote 4931 buffers (30.1%);
0 transaction log file(s) added, 0 removed, 3 recycled;
write=122.946 s, sync=10.129 s, total=133.252 s;
sync files=6, longest=9.854 s, average=1.790 s
Note that given the small load and table size, pgbench implies random
I/Os and basically nothing else.
--
Fabien.
From | Date | Subject | |
---|---|---|---|
Next Message | Fabien COELHO | 2014-08-31 09:36:36 | Re: improving speed of make check-world |
Previous Message | Kohei KaiGai | 2014-08-31 04:54:23 | Re: [v9.5] Custom Plan API |