Re: Initial queries of day slow

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: Initial queries of day slow
Дата
Msg-id CAHyXU0x=6kk=fChqxb=em2eR0i4BdJsb96-=xr5v6bN5AqhM-w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Initial queries of day slow  (Andrew Sullivan <ajs@crankycanuck.ca>)
Список pgsql-general
On Mon, Apr 7, 2014 at 6:14 AM, Andrew Sullivan <ajs@crankycanuck.ca> wrote:
> On Mon, Apr 07, 2014 at 10:32:59AM +0100, Rebecca Clarke wrote:
>
>> normally execute promptly, are taking a long time when they are executed
>> first thing in the morning (after the database has been inactive for
>> several hours). After the first execution, everything is back to normal.
>
> Just guessing, but perhaps because your system's disk buffers have all
> been blown away, so things that are normally in memory aren't any
> more.  In particular,
>
>> A while back I turned autovacuum off and now instead I run a daily cron at
>> 3am that executes a script which does a VACUUM ANALYZE on each table.
>
> this goes through every table in the database, and probably not in the
> order such that the most-frequently-used tables are last in the set.
> But also, why did you turn off autovacuum?  In the earliest
> implementations of autovacuum that was sometimes worth doing for very
> specific workloads, but in more recent releases (9.1.x certainly
> qualifies) you are much better to tune autovacuum.

yes.  first think to check is iowait (say, via top).  If it's high,
then it could be vanilla cache warm up issue or interference from some
other long running process.  Another possible culprit is host machine
resources getting harvested or re-allocated if you're in a virtualized
environment.

merlin


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

Предыдущее
От: Albe Laurenz
Дата:
Сообщение: Re: Order By and Comparisson
Следующее
От: "Sofer, Yuval"
Дата:
Сообщение: Postgres 9.2.8 crash sporadically on Windows