This is normal. My personal workstation has been up for 16 days, and it shows 65 megs used for swap. The linux kernel looks for things that haven't been accessed in quite a while and tosses them into swap to free up the memory for other uses.
This isn't PostgreSQL's fault, or anything elses. It's how a typical Unix kernel works. I.e. you're seeing a problem that simply isn't there. On Thu, 2004-07-15 at 07:49, Jim Ewert wrote: > With pg_autovaccum it's now at 95M swap; averaging 5MB / day increase with same > load. Cache slightly increases or decreases according to top. > > --- On Tue 07/13, Matthew T. O'Connor < [EMAIL PROTECTED] > wrote: > From: Matthew T. O'Connor [mailto: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Date: Tue, 13 Jul 2004 16:26:09 -0400 > Subject: Re: [PERFORM] Swapping in 7.4.3 > > Jim Ewert wrote:<br>> When I went to 7.4.3 (Slackware 9.1) w/ JDBC, the improvements > are that it doesn't initially take much memory (have 512M) and didn't swap. I ran a > full vaccum and a cluster before installation, however speed degaded to 1 *second* / > update of one row in 150 rows of data, within a day! pg_autovacuum now gives > excellent performance however it is taking 66M of swap; only 270k cached.<br>> > <br><br>Are you saying that your system stays fast now that you are using > <br>pg_autovacuum, but pg_autovacuum is using 66M of memory? Please <br>clarify, > I'm not sure what question you want an answered.<br><br>Matthew<br><br> > > _______________________________________________ > Join Excite! - http://www.excite.com > The most personalized portal on the Web! > > ---------------------------(end of broadcast)--------------------------- > TIP 9: the planner will ignore your desire to choose an index scan if your > joining column's datatypes do not match > ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
