Re: postgresql meltdown on PlanetMath.org

Поиск
Список
Период
Сортировка
От Aaron Krowne
Тема Re: postgresql meltdown on PlanetMath.org
Дата
Msg-id 20030316075206.GE19570@vt.edu
обсуждение исходный текст
Ответ на Re: postgresql meltdown on PlanetMath.org  (Joe Conway <mail@joeconway.com>)
Ответы Re: postgresql meltdown on PlanetMath.org  (Joe Conway <mail@joeconway.com>)
Re: postgresql meltdown on PlanetMath.org  (Logan Bowers <logan@datacurrent.com>)
Список pgsql-performance
> - Keep shared memory use reasonable; your final settings of 64M shared
>   buffers and 16M sort_mem sound OK. In any case, be sure you're not
>   disk-swapping.

Yeah, those seem like reasonable values to me.  But I am not sure I'm
not disk-swapping, in fact it is almost certainly going on here bigtime.

> - If you don't already, run VACUUM ANALYZE on some regular schedule
>   (how often depends on your data turnover rate)

I've done it here and there, especially when things seem slow.  Never
seems to help much; the data turnover isn't high.

> - Possibly consider running REINDEX periodically

Ok thats a new one, I'll try that out.

> - Post the SQL and EXPLAIN ANALYZE output for the queries causing the
>   worst of your woes to the list
> - Are all queries slow, or particular ones?

I'm grouping two separate things together to reply to,  because the
second point answers the first: there's really no single culprit.  Every
SELECT has a lag on the scale of a second; resolving all of the foreign
keys in various tables to construct a typical data-rich page piles up
many of these.   I'm assuming the badness of this depends on how much
swapping is going on.

> Explanations of these can be found by searching the list archives and
> reading the related sections of the manual.

Will check that out, thanks.

> A few questions:
> - What version of Postgres?

7.2.1

> - Have you run VACUUM FULL ANALYZE lately (or at least VACUUM ANALYZE)?

Yes, after a particularly bad slowdown... it didn't seem to fix things.

> - Does the database see mostly SELECTs and INSERTs, or are there many
>   UPDATEs and/or DELETEs too?

Almost exclusively SELECTs.

OK, I have just run a VACUUM FULL ANALYZE and things seem much better...
which would be the first time its really made a difference =)  I tried
comparing an EXPLAIN ANALYZE of a single row select on the main objects
table before and after the vacuum, and the plan didn't change
(sequential scan still), but the response time went from ~1 second to
~5msec!  I'm not really sure what could have happened here
behind-the-scenes since it didn't start using the index, and there
probably weren't more than 10% updated/added rows since the last VACUUM.

I actually thought I had a task scheduled which was running a VACUUM
periodically, but maybe it broke for some reason or another.  Still, I
have not been getting consistent results from running VACUUMs, so I'm
not entirely confident that the book is closed on the problem.

Thanks for your help.

apk

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

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