Re: shared_buffers Question

Поиск
Список
Период
Сортировка
От Joe Lester
Тема Re: shared_buffers Question
Дата
Msg-id 69FC9F49-F088-11D8-BDD7-000A95A58EA0@sweetwater.com
обсуждение исходный текст
Список 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 по дате отправления:

Предыдущее
От: Pierre-Frédéric Caillaud
Дата:
Сообщение: Re: Postgres does not utilize indexes. Why?
Следующее
От: Frank van Vugt
Дата:
Сообщение: Why is the number of dead tuples causing the performance of deferred triggers to degrading so rapidly (exponentionally)?