Re: shared_buffers Question - Mailing list pgsql-performance

From Joe Lester
Subject Re: shared_buffers Question
Date
Msg-id 69FC9F49-F088-11D8-BDD7-000A95A58EA0@sweetwater.com
Whole thread Raw
List pgsql-performance
I'm doing a nightly vacuum... so I don't think that's it, although
should I be doing a FULL vacuum instead? The size of my data directory
is only about 389 MB. I'll take a closer look at file sizes going
forward.


echo "VACUUM ANALYZE VERBOSE;" | /Library/PostgreSQL/bin/psql -U
postgres officelink 2>> vacuum.log


Thanks.



<bold><fontfamily><param>Lucida
Grande</param><x-tad-bigger>From</x-tad-bigger></fontfamily></bold><fontfamily><param>Lucida
Grande</param><x-tad-bigger>:
</x-tad-bigger><bold><x-tad-bigger>"Scott Marlowe"</x-tad-bigger></bold></fontfamily><fontfamily><param>Courier</param>

Your shared buffers are almost certainly not the problem here. 2000

shared buffers is only 16 Megs of ram, max.  More than likely, the

database filled up the data directory / partition because it wasn't

being vacuumed.

</fontfamily>

<fontfamily><param>Courier</param>On Sat, 2004-07-31 at 10:25, Joe
Lester wrote:

> I've been running a postgres server on a Mac (10.3, 512MB RAM) with
200

> clients connecting for about 2 months without a crash. However just

> yesterday the database and all the clients hung. When I looked at
the

> Mac I'm using as the postgres server it had a window up that said
that

> there was no more disk space available to write memory too. I ended
up

> having to restart the whole machine. I would like to configure
postgres

> so that is does not rely so heavily on disk-based memory but,
rather,

> tries to stay within the scope of the 512MB of physical memory in
the

> Mac.





</fontfamily>
I'm doing a nightly vacuum... so I don't think that's it, although
should I be doing a FULL vacuum instead? The size of my data directory
is only about 389 MB. I'll take a closer look at file sizes going
forward.

echo "VACUUM ANALYZE VERBOSE;" | /Library/PostgreSQL/bin/psql -U
postgres officelink 2>> vacuum.log

Thanks.


From: "Scott Marlowe"
Your shared buffers are almost certainly not the problem here. 2000
shared buffers is only 16 Megs of ram, max.  More than likely, the
database filled up the data directory / partition because it wasn't
being vacuumed.

On Sat, 2004-07-31 at 10:25, Joe Lester wrote:
 > I've been running a postgres server on a Mac (10.3, 512MB RAM) with
200
 > clients connecting for about 2 months without a crash. However just
 > yesterday the database and all the clients hung. When I looked at the
 > Mac I'm using as the postgres server it had a window up that said that
 > there was no more disk space available to write memory too. I ended up
 > having to restart the whole machine. I would like to configure
postgres
 > so that is does not rely so heavily on disk-based memory but, rather,
 > tries to stay within the scope of the 512MB of physical memory in the
 > Mac.





pgsql-performance by date:

Previous
From: Pierre-Frédéric Caillaud
Date:
Subject: Re: Postgres does not utilize indexes. Why?
Next
From: Frank van Vugt
Date:
Subject: Why is the number of dead tuples causing the performance of deferred triggers to degrading so rapidly (exponentionally)?