Re: high load caused by I/O - a hint

From: Grega Bremec <grega(dot)bremec(at)noviforum(dot)si>
To: eleven <eleven(at)ludojad(dot)itpp(dot)pl>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: high load caused by I/O - a hint
Date: 2004-08-18 08:51:54
Message-ID: 20040818085154.GA27512@elbereth.noviforum.si
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

...and on Wed, Aug 18, 2004 at 10:18:19AM +0200, eleven used the keyboard:
> Hello,
>
> This is not strictly PostgreSQL performance hint, but may be
> helpful to someone with problems like mine.
>
> As I earlier posted, I was experiencing very high load average
> on one of my Linux database servers (IBM eServer 345, SCSI disks on LSI
> Logic controller) caused by I/O bottleneck.
>
> INSERTs were really slow, even after many days of
> tweaking PostgreSQL configuration. The problem appeared to be
> in the Linux kernel itself - using acpi=ht and noapic boot parameters
> solved my performance problems. Load average dropped below 1.0
> (before, it was as high as ten in peak) and the database
> works much, much faster.

Hello,

Did you try with acpi=noidle? This proved to be of help on many an
occasion before, and you don't have to give up any functionality over
it. It's just that the ACPI BIOS is broken and overloads the system
with idle calls.

Other than that, general guidelines would be, don't combine APM and
ACPI, and rather use proper SMP code for hyperthreaded machines than
just the ACPI CPU enumeration feature.

There's also a new option with 2.6.8.1, called CONFIG_SCHED_SMT that
is supposed to handle some cases SMP code had problems with better,
at the cost of slight overhead in other areas.

My advice would be, if you have an option to choose between APM and
ACPI, go for ACPI. It's the future, it's being developed actively,
it does a whole lot more than APM (that was really only about power
management), and last but not least, I've been using it for four
years on over fifty SMP machines and I never ever had a problem
beyond the scope of what noidle could fix (knocks-on-wood). :)

HTH,
--
Grega Bremec
Senior Administrator
Noviforum Ltd., Software & Media
http://www.noviforum.si/

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Frank van Vugt 2004-08-18 09:24:56 Re: Why is the number of dead tuples causing the performance of deferred triggers to degrade so rapidly (exponentionally)?
Previous Message eleven 2004-08-18 08:18:19 high load caused by I/O - a hint