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

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.

--
11.

...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/

eleven wrote:

> 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.

I suggest you to investigate why noapic did the work for you, do you have
not well supported device ? At your place also I'd try removing the noapic
option and using acpi=noidle



Regards
Gaetano Mendola

On Aug 18, 2004, at 4:18 AM, eleven wrote:

> 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.
>

We have some 335's (I think they are 335s) and until April or so there
was a bug in the Fusion MPT driver that would cause it to revert to
async narrow mode if hardware RAID was enabled on it.  (Performance was
horrible - NFS on a 100meg network was 10x faster than local disk!) And
on the upside, when I originally researched the problem they hadn't
found the bug yet so there were no others around having issues like
mine so trying to figure it out was quite difficult.

I may see if using that acpi=ht makes any difference as well.

--
Jeff Trout <jeff@jefftrout.com>
http://www.jefftrout.com/
http://www.stuarthamm.net/