On Tue, Aug 3, 2010 at 11:37 AM, Yeb Havinga <yebhavinga@xxxxxxxxx> wrote: > Yeb Havinga wrote: >> >> Hannu Krosing wrote: >>> >>> Did it fit in shared_buffers, or system cache ? >>> >> >> Database was ~5GB, server has 16GB, shared buffers was set to 1920MB. >>> >>> I first noticed this several years ago, when doing a COPY to a large >>> table with indexes took noticably longer (2-3 times longer) when the >>> indexes were in system cache than when they were in shared_buffers. >>> >> >> I read this as a hint: try increasing shared_buffers. I'll redo the >> pgbench run with increased shared_buffers. > > Shared buffers raised from 1920MB to 3520MB: > > pgbench -v -l -c 20 -M prepared -T 1800 test > starting vacuum...end. > starting vacuum pgbench_accounts...end. > transaction type: TPC-B (sort of) > scaling factor: 300 > query mode: prepared > number of clients: 20 > duration: 1800 s > number of transactions actually processed: 12971714 > tps = 7206.244065 (including connections establishing) > tps = 7206.349947 (excluding connections establishing) > > :-) 1) what can we comparing this against (changing only the shared_buffers setting)? 2) I've heard that some SSD have utilities that you can use to query the write cycles in order to estimate lifespan. Does this one, and is it possible to publish the output (an approximation of the amount of work along with this would be wonderful)? merlin -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
