Hi Mark, Good to see you producing results again. On Sat, 2008-12-20 at 16:54 -0800, Mark Wong wrote: > Here are links to how the throughput changes when increasing shared_buffers: > > http://pugs.postgresql.org/node/505 Only starnge thing here is the result at 22528MB. It's the only normal one there. Seems to be a freeze occurring on most tests around the 30 minute mark, which delays many backends and reduces writes. Reduction in performance as shared_buffers increases looks normal. Increase wal_buffers, but look for something else as well. Try to get a backtrace from when the lock up happens. It may not be Postgres? > And another series of tests to show how throughput changes when > checkpoint_segments are increased: > > http://pugs.postgresql.org/node/503 > > The links go to a graphical summary and raw data. Note that the > maximum theoretical throughput at this scale factor is approximately > 12000 notpm. > > My first glance takes tells me that the system performance is quite > erratic when increasing the shared_buffers. I'm also not what to > gather from increasing the checkpoint_segments. Is it simply that the > more checkpoint segments you have, the more time the database spends > fsyncing when at a checkpoint? I would ignore the checkpoint_segment tests because you aren't using a realistic value of shared_buffers. I doubt any such effect is noticeable when you use a realistic value determined from set of tests 505. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
