From owner-freebsd-database@FreeBSD.ORG Fri Jul 25 00:15:27 2003 Return-Path: Delivered-To: freebsd-database@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B366C37B401; Fri, 25 Jul 2003 00:15:27 -0700 (PDT) Received: from puffin.mail.pas.earthlink.net (puffin.mail.pas.earthlink.net [207.217.120.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id EADB143FAF; Fri, 25 Jul 2003 00:15:26 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-2ivfi6b.dialup.mindspring.com ([165.247.200.203] helo=mindspring.com) by puffin.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19fwmu-00062u-00; Fri, 25 Jul 2003 00:14:49 -0700 Message-ID: <3F20D8A8.6FA1C790@mindspring.com> Date: Fri, 25 Jul 2003 00:13:44 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Christopher Weimann References: <200307191818.13516.paul@pathiakis.com> <20030720110939.GN24507@perrin.int.nxad.com> <20030720164237.GC55392@nasby.net> <20030722143449.B10666@smtp.k12us.com> <3F1E297E.70962D97@mindspring.com> <20030723144700.GL55392@nasby.net> <3F1F82DD.966C7F2F@mindspring.com> <20030724173910.GA9364@smtp.k12us.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4c4d372233ee63315d328c02106f30f8e93caf27dac41a8fd350badd9bab72f9c350badd9bab72f9c cc: Sean Chittenden cc: freebsd-database@freebsd.org cc: freebsd-performance@freebsd.org cc: Paul Pathiakis Subject: Re: Tuning for PostGreSQL Database X-BeenThere: freebsd-database@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Database use and development under FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2003 07:15:28 -0000 Christopher Weimann wrote: > So if PostGreSQL uses fsync when writing ( which I think is only true > on the write-ahead logs at this point ) that data will NOT wind up in > the cache. Anything that PostGreSQL reads should wind up in the cache? No; fsync'ed data pages are in the cache as clean pages containing data, until they are inactivated, or until you madvise them away, etc.. One common practice is to madvise(DONTNEED), which basically moves the pages to the other end of the LRU, so that they will be stolen and given back to the system first, rather than putting them on the LRU in access order, which means other pages would be at risk first. Probably reading the decriptions in the madvise man page would be a useful exercise for you, since it talks about the states that the vmobject_t's and pages in them can be in at any given time, with specific regard to FreeBSD. As I said before, there's really no good documentation, except the source code, and to undestand what top's numbers means, you have to understand how top gets those numbers in the first place, then you have to reverse the math to get the statictics values it's using and their effect on the values displayed by top, and then you have to look at the VM code that changes each of those statistics (in the "vmmeter" structure) to see what conditions cause a state change on a page. Short of writing better documentation, that's about all I can tell you about it without defacto writing better documentation. The problem with writing better documentation is that then some idiot will understand the code, and, understanding it, either fix or try to fix any shortcomings described in the documentation, and fail to update the documentation in the process, at which point the documentation will be near-instantly out of date. It's like comparing Linux and FreeBSD: as soon as you do a valid comparison which honestly shows a difference between the two, an army of people who don't value accurate documentation rush out to correct any discrepancies in performance, and then a week after you've published your comparison, someone's trying to blow up your car for publishing "lies" about their favorite OS ("That's not true! You're a disreputable scoundrel!"). > last pid: 58622; load averages: 1.96, 1.67, 1.47 up 2+12:59:15 13:31:39 > 130 processes: 6 running, 124 sleeping > > Mem: 348M Active, 2628M Inact, 438M Wired, 155M Cache, 380M Buf, 76M Free > Swap: 4096M Total, 28K Used, 4096M Free > > The 2628M Inact is likley to be acting as cache? > > Basically I should stop worrying about this :) Or go read the top sources and the VM code, yes. -- Terry