Increasing checkpoint distance helps 7.2 noticeably
Вложения
В списке pgsql-hackers по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Increasing checkpoint distance helps 7.2 noticeably |
| Дата | |
| Msg-id | 17608.1010631664@sss.pgh.pa.us обсуждение |
| Список | pgsql-hackers |
The attached curves are for pgbench in a scale-factor-500 database, postmaster options -F -N 100 -B 3800 on a 4-way Linux machine, current CVS sources. I noticed that with the default WAL options, the system was spawning a checkpoint process every fifteen seconds or so during the pgbench run. Bad news. (Aside from the I/O implied by the checkpoint itself, there's a big penalty in increased WAL traffic, since the first update of any page after a checkpoint dumps that whole page to WAL.) I bumped up the checkpoint_segments parameter to ensure checkpoints wouldn't happen so frequently, and for good measure kicked wal_files up too. As you can see, it helped noticeably --- at the price of several times as much WAL disk space, of course. Curiously, I'm seeing no improvement whatever from increasing checkpoint_segments and wal_files in 7.1.3 on the same hardware and same test conditions. 7.2 has a better algorithm for managing WAL segments (recycle rather than delete and recreate), but still it seems odd that 7.1.3 can't benefit at all. BTW, has anyone experimented with the OSDB benchmark at http://osdb.sourceforge.net/ ? I'm wondering if it might give more useful numbers than pgbench does. regards, tom lane
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера
