Re: Postgres filling up hard drive with swap files

> 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.

Thanks for the response, Jeff. The RPRVT, which you say is best to go
by, shows only 4K-2MB per connection. That's less than the 4-8MB size
you reference which I believe comes from the RSIZE column in top. So
according to RSIZE I should add more RAM. But according to RPRVT I
should be OK with 512 MB of RAM. I'm a little confused on which column
to go by.

Also, even if I need to add more RAM, it still strikes me as more than
a little weird that a memory overflow situation gradually eats up all
the space on my hard drive. That's the problem I'd really like to solve
if possible.

PID COMMAND      %CPU   TIME   #TH #PRTS #MREGS RPRVT  RSHRD  RSIZE
VSIZE
14378 postgres     0.0%  0:00.41   1     9    33   880K  17.8M  8.31M
60.0M
14359 postgres     0.0%  0:00.90   1     9    32   860K  17.8M  4.12M
59.5M
14346 postgres     0.0%  0:00.31   1     9    32   840K  17.8M  2.26M
59.5M
14342 postgres     0.0%  0:01.08   1     9    33   880K  17.8M  7.86M
60.0M
14290 postgres     0.0%  0:00.55   1     9    32   868K  17.8M  3.09M
59.5M
14235 postgres     0.0%  0:03.39   1     9    33   880K  17.8M  7.68M
60.0M
14224 postgres     0.0%  0:00.43   1     9    32   864K  17.8M  2.55M
59.5M
14220 postgres     0.0%  0:00.40   1     9    33   888K  17.8M  3.02M
60.0M
14218 postgres     0.0%  1:07.53   1     9    33  2.04M  17.8M  10.9M
60.0M
14075 postgres     0.0%  1:40.98   1     9    33   872K  17.8M  10.5M
60.0M
14063 postgres     0.0%  0:00.55   1     9    33   892K  17.8M  3.27M
60.0M

> 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)

Huh. Cool. Do you have any experience of what the performance hit would
be for using pgpool?