Re: Config review

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: Bryan Vest <bvest(at)bright(dot)net>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Config review
Date: 2004-12-07 15:07:54
Message-ID: 15131.1102432074@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Greg Stark <gsstark(at)mit(dot)edu> writes:
> Bryan Vest <bvest(at)bright(dot)net> writes:
>> Currently the database is at a size of 87.6Gig. A Vacuum Analyze runs every
>> night and has been taking 4 or 5 hours to complete. Everything seems to run
>> fine for a while, then at some point the load goes through the roof and the
>> iowait % also goes way up. It will recover after a little bit and then do the
>> same thing all over again.

> While others have pointed out problems with the config I don't think any of
> them explains this irregular behaviour.

As Greg says, it might be checkpoints or a background query. If it
actually is the vacuum itself causing the variation in load, the theory
that comes to mind is that the performance tanks when the vacuum run
switches from find-dead-tuples to clean-indexes mode; clean-indexes is
usually a lot more I/O intensive.

ISTM it actually doesn't matter much which of these explanations is
correct, because all three imply the same thing: not enough disk I/O
bandwidth. The disk is near saturation already and any increase in
demand drives response time over the knee of the curve.

If you are using a RAID configuration it might just be that you need
to adjust the configuration (IIRC, there are some RAID setups that
are not very write-friendly). Otherwise you may have little alternative
but to buy faster disks.

regards, tom lane

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Andrew Sullivan 2004-12-07 15:19:26 Re: Config review
Previous Message Bruno Wolff III 2004-12-07 14:52:33 Re: Fwd: 8.0 vs. 7.4 benchmarks