Received: from primo.verat.net (primo.verat.net [217.26.64.130]) by postgresql.org (8.11.3/8.11.1) with ESMTP id f6CGFWa36986 for ; Thu, 12 Jul 2001 12:15:33 -0400 (EDT) (envelope-from snpe@snpe.co.yu) Received: from spnew (ppp65-122.verat.net [217.26.65.122]) by primo.verat.net (8.10.2/8.10.2/AmigaOS 5.0 YAMD) with SMTP id f6CGFTX01009 for ; Thu, 12 Jul 2001 18:15:29 +0200 X-Authentication-Warning: primo.verat.net: Host ppp65-122.verat.net [217.26.65.122] claimed to be spnew Content-Type: text/plain; charset="iso-8859-1" From: snpe To: pgsql-general@postgresql.org Subject: Re: Performance tuning for linux, 1GB RAM, dual CPU? Date: Thu, 12 Jul 2001 19:18:23 +0200 X-Mailer: KMail [version 1.2] References: <5146853DD571D411AC54000102070D611C7F10@MINGBGNTS02> <20010712134958W.t-ishii@sra.co.jp> <16987.994947657@sss.pgh.pa.us> In-Reply-To: <16987.994947657@sss.pgh.pa.us> MIME-Version: 1.0 Message-Id: <01071219182300.01463@spnew> Content-Transfer-Encoding: 8bit X-Archive-Number: 200107/440 X-Sequence-Number: 12419 > 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. > You can lock shared memory for this problem ? regards haris peco