public inbox for [email protected]  

help / color / mirror / Atom feed

From: Tom Lane <[email protected]>
To: Tatsuo Ishii <[email protected]>
Cc: [email protected]
Cc: [email protected]
Subject: Re: Performance tuning for linux, 1GB RAM, dual CPU?
Date: Thu, 12 Jul 2001 10:20:57 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <5146853DD571D411AC54000102070D611C7F10@MINGBGNTS02>
	<[email protected]>
	<[email protected]>

Tatsuo Ishii <[email protected]> writes:
> In my testing with *particluar* environment (Linux kernel 2.2.x,
> pgbench), it was indicated that too many shared buffers reduced the
> performance even though there was lots of memory, say 1GB. I'm not
> sure why, but I suspect there is a siginificant overhead to lookup
> shared buffers.

Regular lookups use a hash table, and shouldn't suffer much from
degraded performance as NBuffers rises.  However, there are some
operations that do a linear scan of all the buffers --- table deletion
comes to mind.  Perhaps your test was exercising one of these.

pgbench doesn't do table deletions of course... hmm... the only
such loop in bufmgr.c that looks like it would be executed during
normal transactions is BufferPoolCheckLeak().  Maybe we should
make that routine be a no-op unless assert checking is turned on?
Have we reached the point where performance is more interesting than
error checking?  It'd be interesting to retry your results with
BufferPoolCheckLeak() reduced to "return false".

Another factor, not under our control, is that if the shared memory
region gets too large the kernel may decide to swap out portions of
it that haven't been touched lately.  This of course is completely
counterproductive, especially if what gets swapped is a dirty buffer,
which'll eventually have to be read back in and then written to where
it should have gone.  This is the main factor behind my thought that you
don't want to skimp on kernel disk buffer space --- any memory pressure
in the system should be resolvable by dropping kernel disk buffers, not
by starting to swap shmem or user processes.

			regards, tom lane

view thread (14+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: Performance tuning for linux, 1GB RAM, dual CPU?
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox