On Mon, Aug 10, 2015 at 3:09 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: > On Thu, Aug 6, 2015 at 12:24 PM, Haribabu Kommi <kommi.harib...@gmail.com> > wrote: > > What is the configuration for test (RAM of m/c, shared_buffers, > scale_factor, etc.)?
Here are the details: CPU - 16 core, RAM - 252 GB shared_buffers - 1700MB, buffer_cache_ratio - 70 wal_buffers - 16MB, synchronous_commit - off checkpoint_timeout - 15min, max_wal_size - 5GB. pgbench scale factor - 75 (1GB) Load test table size - 1GB >> Threads Head Patched Diff >> 1 3123 3238 3.68% >> 2 5997 6261 4.40% >> 4 11102 11407 2.75% >> >> I am suspecting that, this may because of buffer locks that are >> causing the problem. >> where as in older approach of different buffer pools, each buffer pool >> have it's own locks. >> I will try to collect the profile output and analyze the same. >> >> Any better ideas? >> > > I think you should try to find out during test, for how many many pages, > it needs to perform clocksweep (add some new counter like > numBufferBackendClocksweep in BufferStrategyControl to find out the > same). By theory your patch should reduce the number of times it needs > to perform clock sweep. > > I think in this approach even if you make some buffers as non-replaceable > (buffers for which BM_BUFFER_CACHE_PAGE is set), still clock sweep > needs to access all the buffers. I think we might want to find some way to > reduce that if this idea helps. > > Another thing is that, this idea looks somewhat similar (although not same) > to current Ring Buffer concept, where Buffers for particular types of scan > uses buffers from Ring. I think it is okay to prototype as you have done > in patch and we can consider to do something on those lines if at all > this patch's idea helps. Thanks for the details. I will try the same. Regards, Hari Babu Fujitsu Australia -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
