Re: wal_buffers, redux
| От | Robert Haas |
|---|---|
| Тема | Re: wal_buffers, redux |
| Дата | |
| Msg-id | CA+TgmobjYLxLojw2SaDnPX6ch7LtbdrK0QSJ5czsTXiVg8OTCA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: wal_buffers, redux (Josh Berkus <josh@agliodbs.com>) |
| Ответы |
Re: wal_buffers, redux
|
| Список | pgsql-hackers |
On Tue, Mar 13, 2012 at 6:44 PM, Josh Berkus <josh@agliodbs.com> wrote: >> That's a speedup of nearly a factor of two, so clearly fsync-related >> stalls are a big problem here, even with wal_buffers cranked up >> through the ceiling. > > Hmmmm. Do you have any ability to test on XFS? It seems I do. XFS, with fsync = on: tps = 14746.687499 (including connections establishing) XFS, with fsync = off: tps = 25121.876560 (including connections establishing) No real dramatic difference there, maybe a bit slower. On further thought, it may be that this is just a simple case of too many checkpoints. With fsync=off, we don't have to actually write all that dirty data back to disk. I'm going to try cranking up checkpoint_segments and see what happens. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: