Re: New to PostgreSQL, performance considerations
От | Alvaro Herrera |
---|---|
Тема | Re: New to PostgreSQL, performance considerations |
Дата | |
Msg-id | 20061212161106.GF22782@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: New to PostgreSQL, performance considerations (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: New to PostgreSQL, performance considerations
Re: New to PostgreSQL, performance considerations |
Список | pgsql-performance |
Tom Lane wrote: > Alexander Staubo <alex@purefiction.net> writes: > > No, fsync=on. The tps values are similarly unstable with fsync=off, > > though -- I'm seeing bursts of high tps values followed by low-tps > > valleys, a kind of staccato flow indicative of a write caching being > > filled up and flushed. > > It's notoriously hard to get repeatable numbers out of pgbench :-( > > A couple of tips: > * don't put any faith in short runs. I usually use -t 1000 > plus -c whatever. > * make sure you loaded the database (pgbench -i) with a scale > factor (-s) at least equal to the maximum -c you want to test. > Otherwise you're mostly measuring update contention. > * pay attention to when checkpoints occur. You probably need > to increase checkpoint_segments if you want pgbench not to be > checkpoint-bound. While skimming over the pgbench source it has looked to me like it's necessary to pass the -s switch (scale factor) to both the initialization (-i) and the subsequent (non -i) runs. I'm not sure if this is obvious from the documentation but I thought it may be useful to mention.
В списке pgsql-performance по дате отправления: