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
decreasesaccording to top.
>
> --- On Tue 07/13, Matthew T. O'Connor < matthew@zeut.net > wrote:
> From: Matthew T. O'Connor [mailto: matthew@zeut.net]
> To: jim.ewert@excite.com
> Cc: pgsql-performance@postgresql.org
> 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
takemuch memory (have 512M) and didn't swap. I ran a full vaccum and a cluster before installation, however speed
degadedto 1 *second* / update of one row in 150 rows of data, within a day! pg_autovacuum now gives excellent
performancehowever it is taking 66M of swap; only 270k cached.<br>> <br><br>Are you saying that your system stays fast
nowthat you are using <br>pg_autovacuum, but pg_autovacuum is using 66M of memory? Please <br>clarify, I'm not sure
whatquestion 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
>