Received: from sss.pgh.pa.us ([192.204.191.242]) by postgresql.org (8.11.3/8.11.1) with ESMTP id f6BGq9a60926 for ; Wed, 11 Jul 2001 12:52:09 -0400 (EDT) (envelope-from tgl@sss.pgh.pa.us) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id f6BGpxJ23764; Wed, 11 Jul 2001 12:51:59 -0400 (EDT) To: Christian Bucanac cc: "Pgsql-General (E-mail)" Subject: Re: Performance tuning for linux, 1GB RAM, dual CPU? In-reply-to: <5146853DD571D411AC54000102070D611C7F10@MINGBGNTS02> References: <5146853DD571D411AC54000102070D611C7F10@MINGBGNTS02> Comments: In-reply-to Christian Bucanac message dated "Sun, 11 Jul 2038 17:13:10 +0200" Date: Wed, 11 Jul 2001 12:51:59 -0400 Message-ID: <23761.994870319@sss.pgh.pa.us> From: Tom Lane X-Archive-Number: 200107/394 X-Sequence-Number: 12364 Christian Bucanac writes: >> I am going to try 768M (98304) for buffers and 6144 (6144 * 32 = 192M) >> for sort mem. This way with the DB server serving a max of 32 application >> servers the kernel and other processes should still have the last 64Mb RAM. This is almost certainly a lousy idea. You do *not* want to chew up all available memory for PG shared buffers; you should leave a good deal of space for kernel-level disk buffers. Other fallacies in the above: (1) you're assuming the SortMem parameter applies once per backend, which is not the case (it's once per sort or hash step in a query, which could be many times per backend); (2) you're not allowing *anything* for any space usage other than shared disk buffers and sort memory. The rule of thumb I recommend is to use (at most) a quarter of real RAM for shared disk buffers. I don't have hard measurements to back that up, but I think it's a lot more reasonable as a starting point than three-quarters of RAM. regards, tom lane