Re: PostgreSQL strugling during high load

От: Mischa Sandberg
Тема: Re: PostgreSQL strugling during high load
Дата: ,
Msg-id: 1116005602.4284e4e28869e@webmail.telus.net
(см: обсуждение, исходный текст)
Ответ на: Re: PostgreSQL strugling during high load  (Tom Lane)
Список: pgsql-performance

Скрыть дерево обсуждения

PostgreSQL strugling during high load  ("Mindaugas Riauba", )
 Re: PostgreSQL strugling during high load  ("Steinar H. Gunderson", )
 Re: PostgreSQL strugling during high load  (Tom Lane, )
  Re: PostgreSQL strugling during high load  (Mischa Sandberg, )
 Re: PostgreSQL strugling during high load  ("Mindaugas Riauba", )
  Re: PostgreSQL strugling during high load  (Tom Lane, )
   Re: PostgreSQL strugling during high load  (Donald Courtney, )
  Re: PostgreSQL strugling during high load  (Cosimo Streppone, )
  Re: PostgreSQL strugling during high load  ("Matthew T. O'Connor", )
   Re: PostgreSQL strugling during high load  ("Thomas F. O'Connell", )
 Re: PostgreSQL strugling during high load  ("Mindaugas Riauba", )
  Re: PostgreSQL strugling during high load  ("Steinar H. Gunderson", )
 Re: PostgreSQL strugling during high load  ("Mindaugas Riauba", )
  Re: PostgreSQL strugling during high load  (Tom Lane, )
 Re: PostgreSQL strugling during high load  ("Mindaugas Riauba", )
 Re: PostgreSQL strugling during high load  ("Anjan Dave", )
  Re: PostgreSQL strugling during high load  (Donald Courtney, )
  Re: PostgreSQL strugling during high load  (Vivek Khera, )
  Re: PostgreSQL strugling during high load  (Josh Berkus, )
   Re: PostgreSQL strugling during high load  (Steve Poe, )
 Re: PostgreSQL strugling during high load  ("Anjan Dave", )

Quoting Tom Lane <>:

> "Mindaugas Riauba" <> writes:
> > ... So contents of database changes very fast. Problem is that
> when
> > pg_autovacuum does vacuum those changes slows down too much.
>
> The "vacuum cost" parameters can be adjusted to make vacuums fired
> by pg_autovacuum less of a burden.  I haven't got any specific
> numbers
> to suggest, but perhaps someone else does.

I solved one problem by cranking sleep scaling to -S 20.
It made pg_autovacuum back off longer during extended periods of heavy
disk-intensive query activity. Our update activity is near-constant
insert rate, then once or twice a day, massive deletes.
--
Dreams come true, not free.



В списке pgsql-performance по дате сообщения:

От: John Arbash Meinel
Дата:
Сообщение: Re: Optimize complex join to use where condition before
От: David Brown
Дата:
Сообщение: Re: ok you all win what is best opteron (I dont want a