PostgreSQL strugling during high load

От: Mindaugas Riauba
Тема: PostgreSQL strugling during high load
Дата: ,
Msg-id: 01cc01c557ba$a4fdb0b0$f20214ac@bite.lt
(см: обсуждение, исходный текст)
Ответы: Re: PostgreSQL strugling during high load  ("Steinar H. Gunderson")
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", )

  Hello,

  We have problems with one postgresql database with high
data change rate. Actually we are already under pressure
to change postgresql to Oracle.

  I cannot post schema and queries to list but can do this
privately.

  Tables are not big (20000-150000 rows each) but have very high
turnover rate - 100+ updates/inserts/deletes/selects per second.
So contents of database changes very fast. Problem is that when
pg_autovacuum does vacuum those changes slows down too much.
And we keep autovacuum quite aggressive (-v 1000 -V 0.5 -a 1000
-A 0.1 -s 10) to not bloat database and to avoid bigger impact.
analyze seems not to impact performance too much.

  Tables have 2-3 indexes each and one table have foreign key
contraint. Postgresql is 8.0.1. vmstat shows that IO and CPU are
not saturated. DB is on RAID1+0 controller with battery backed write
cache.

  What can we tune to improve performance in our case? Please help
to defend PostgreSQL against Oracle in this case :).

  Thanks,

  Mindaugas



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

От: Markus Bertheau
Дата:
Сообщение: Re: Bad plan after vacuum analyze
От: "Joel Fradkin"
Дата:
Сообщение: ok you all win what is best opteron (I dont want a hosed system again)