Обсуждение: Swapping in 7.4.3
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* / updateof one row in 150 rows of data, within a day! pg_autovacuum now gives excellent performance however it is taking 66Mof swap; only 270k cached. _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web!
Jim Ewert wrote: > 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* / updateof one row in 150 rows of data, within a day! pg_autovacuum now gives excellent performance however it is taking 66Mof swap; only 270k cached. > Are you saying that your system stays fast now that you are using pg_autovacuum, but pg_autovacuum is using 66M of memory? Please clarify, I'm not sure what question you want an answered. Matthew
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 take
muchmemory (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
itis 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
wantan answered.<br><br>Matthew<br><br>
_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!
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 >
> 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. Actually it (and other OSes) does slightly better than that. It _copies_ the least recently used pages into swap, but leaves them in memory. Then when there really is a need to swap stuff out there is no need to actually write to swap because it's already been done, and conversely if those pages are wanted then they don't have to be read from disk because they were never removed from memory.