Skip site navigation (1) Skip section navigation (2)

Re: Postgres filling up hard drive with swap files

From: Jeff <threshar(at)torgo(dot)978(dot)org>
To: Joe Lester <joe_lester(at)sweetwater(dot)com>
Cc: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>,postgres list <pgsql-general(at)postgresql(dot)org>
Subject: Re: Postgres filling up hard drive with swap files
Date: 2004-08-20 18:28:43
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-general
On Aug 20, 2004, at 2:09 PM, Joe Lester wrote:

> 14326 top         19.7%  0:03.13   1    17    26   364K   384K   740K  
> 27.1M
> 14293 bash         0.0%  0:00.13   1    12    18   124K   852K   796K  
> 18.2M
> 14291 sshd         0.0%  0:00.49   1    15    42   504K   884K  1.43M  
> 30.0M
> 14290 postgres     0.0%  0:00.31   1     9    32   860K  16.9M  6.90M  
> 59.5M

On osx the number to look at isn't vsize, but actually rprvt.  vsize is 
its size in virtual memory (basically useless)- rprvt is the size of 
its "private memory" - non shared memory. It is a pretty good number to 
go by.

But I believe the whole problem is the emac only has 512MB of ram and 
you simply don't have enough memory for that many connections.  Even 
with each connection sucking up 2MB of memory that is 400MB and as you 
can see.. most of them are sucking 4-8MB.

If you cannot upgrade I'd recommend looking into something like pgpool 
so you can pool your connections (this results in having a lot fewer 
instances of postgres, thus saving tons of memory)

If you watch top I'm guessing you'll see a TON of pagein/pageouts 
(watch the numbers change. it displays the difference in parenthesis 
after updates)

Jeff Trout <jeff(at)jefftrout(dot)com>

In response to


pgsql-general by date

Next:From: Joe LesterDate: 2004-08-20 18:33:21
Subject: Re: Postgres filling up hard drive with swap files
Previous:From: Tom LaneDate: 2004-08-20 18:24:19
Subject: Re: How to setup default value "0000-00-00" for "date"

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group