Re: postgresql meltdown on PlanetMath.org

Поиск
Список
Период
Сортировка
От Aaron Krowne
Тема Re: postgresql meltdown on PlanetMath.org
Дата
Msg-id 20030316080601.GF19570@vt.edu
обсуждение исходный текст
Ответ на Re: postgresql meltdown on PlanetMath.org  (Sean Chittenden <sean@chittenden.org>)
Ответы Re: postgresql meltdown on PlanetMath.org  (Sean Chittenden <sean@chittenden.org>)
Список pgsql-performance
> Have you read the following?
> http://developer.postgresql.org/docs/postgres/performance-tips.html

Yup.  I would never go and bother real people without first checking the
manual, but I bet you get a lot of that =)

> This shouldn't be an issue for the load you describe.  A p-100 should
> be okay, but it depends on your queries that you're performing.

Mostly just gather-retrieval based on unique identifier keys in a bunch
of tables.  Really mundane stuff.

> *) Stick with btree's.

Yeah, that saddens me, though =)  When I initially switched to hashes,
things were blazing.  This application makes heavy use of keys and equal
comparisons on indices, so hashes are really the optimal index
structure.  I'd like to be able to go back to using them some day... if
not for the concurrency issue, which seems like it should be fixable
(even having mutually exclusive locking on the entire index would
probably be fine for this application and would prevent deadlock).

> > - I then tried increasing the machines shared memory max to 75% of the
> >   physical memory, and scaled postgresql's buffers accordingly.  This
> *) Don't do this, go back to near default levels.  I bet this is
>  hurting your setup.
> > - Lastly, I tried reducing the shared memory max and limiting postgresql
> >   to more conservative values, although still not to the out-of-box
> >   values.  Right now shared memory max on the system is 128mb,
> >   postgres's shared buffers are at 64mb, sort_mem is at 16mb, and
> >   effective cache size is at 10mb.
> *) You shouldn't have to do this either.

Well, I've now been advised that the best way is all 3 that I have tried
(among aggressive buffering, moderate buffering, and default
conservative buffering).

Perhaps you could explain to me why the system shouldn't be ok with the
moderate set of buffer sizes on a 512mb machine?  I don't really know
enough about the internals of postgres to be doing anything but voodoo
when I change the values.

> I hate to say this, but this sounds like a config error.  :-/

Thats better than a hardware error!  This is what I wanted to hear =)

> *) Have you done a vacuum analyze?

See previous message to list (summary: it worked this time, but usually
it does not help.)

Thanks,

Aaron Krowne

В списке pgsql-performance по дате отправления:

Предыдущее
От: Aaron Krowne
Дата:
Сообщение: Re: postgresql meltdown on PlanetMath.org
Следующее
От: Sean Chittenden
Дата:
Сообщение: Re: postgresql meltdown on PlanetMath.org