Re: BUG #5284: Postgres CPU 100% and worker took too long to start; cancelled... Systemdown

From: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
To: yua ゅぁ <azuneko(at)hotmail(dot)com>
Cc: kevin(dot)grittner(at)wicourts(dot)gov, robertmhaas(at)gmail(dot)com, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #5284: Postgres CPU 100% and worker took too long to start; cancelled... Systemdown
Date: 2010-01-26 23:38:05
Message-ID: 4B5F7CDD.8050008@postnewspapers.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 26/01/2010 8:58 AM, yua ゅぁ wrote:

> RAID Card : LSI MegaRAID
> Battery Cache : YES
> write-back Cache : NO
> Software RAID : NO ( Hardware RAID)

The LSI MegaRAID series are, AFAIK, software raid implementations. The
hardware has some BIOS hooks to enable boot-loading, then the OS loads a
driver that does all the real work for the RAID implementation.

... though a quick Google search suggests they may be using that brand
for real RAID hardware too, so without specifying the model number it's
hard to know what your RAID hardware is. The fact that your card has a
BBU tends to confirm they're making real RAID hardware under that name.

It probably doesn't make much difference in this particular case,
though, as disk I/O is unlikely to be part of your issue.

> SAN : NO
> Disk : 7,200rpm SATA 3lot
> Disk : RAID5 3slot

Again it's not the cause of the problem you report, but: Most databases,
and certainly PostgreSQL, perform poorly on RAID 5. In particular,
PostgreSQL really doesn't like having the WAL stored on RAID 5, but
really you're much better off using RAID 10 for all your
database-related storage if you can.

--
Craig Ringer

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Euler Taveira de Oliveira 2010-01-27 00:32:21 Re: Failed to run initdb - not resolved bug 5130
Previous Message Craig Ringer 2010-01-26 23:35:15 Re: BUG #5297: Add XATMI C API