From: Erik Myllymaki <erik.myllymaki@aviawest.com>
To: Mark Lewis <mark.lewis@mir3.com>
Cc: Vivek Khera <vivek@khera.org>
Cc: Pgsql performance <pgsql-performance@postgresql.org>
Subject: Re: hardare config question
Date: Mon, 01 May 2006 10:58:23 -0700
Message-ID: <44564C3F.2040609@aviawest.com> (raw)
In-Reply-To: <1146246441.15712.41.camel@archimedes>
References: <445236D5.5060509@aviawest.com>
<3DFCE70E-E4BB-40AB-B27F-99E90E8159CA@khera.org>
<1146246441.15712.41.camel@archimedes>
I have been in discussion with 3ware support and after adjusting some settings,
the 3ware card in RAID 1 gets better performance than the single drive. I guess
this had everything to do with the write (and maybe read?) cache.
Of course now i am in a dangerous situation - using volatile write cache
without a BBU.
If I were to use a UPS to ensure a soft shutdown in the event of power loss, am
I somewhat as safe as if I were to purchase a BBU for this RAID card?
Thanks.
Mark Lewis wrote:
> It's also possible that the single SATA drive you were testing (or the
> controller it was attached to) is lying about fsync and performing write
> caching behind your back, whereas your new controller and drives are
> not.
>
> You'll find a lot more info on the archives of this list about it, but
> basically if your application is committing a whole lot of small
> transactions, then it will run fast (but not safely) on a drive which
> lies about fsync, but slower on a better disk subsystem which doesn't
> lie about fsync.
>
> Try running a test with fsync=off with your new equipment and if it
> suddenly starts running faster, then you know that's the problem.
> You'll either have a choice of losing all of your data the next time the
> system shuts down uncleanly but being fast, or of running slow, or of
> fixing the applications to use chunkier transactions.
>
> -- Mark
>
> On Fri, 2006-04-28 at 13:36 -0400, Vivek Khera wrote:
>> On Apr 28, 2006, at 11:37 AM, Erik Myllymaki wrote:
>>
>>> When I had this installed on a single SATA drive running from the
>>> PE1800's on-board SATA interface, this operation took anywhere from
>>> 65-80 seconds.
>>>
>>> With my new RAID card and drives, this operation took 272 seconds!?
>> switch it to RAID10 and re-try your experiment. if that is fast,
>> then you know your raid controller does bad RAID5.
>>
>> anyhow, I have in one server (our office mail server and part-time
>> development testing box) an adaptec SATA RAID from dell. it is
>> configured for RAID5 and does well for normal office stuff, but when
>> we do postgres tests on it, it just is plain old awful.
>>
>> but I have some LSI based cards on which RAID5 is plenty fast and
>> suitable for the DB, but those are SCSI.
>>
>> For what it is worth, the Dell PE1850 internal PERC4/Si card is
>> wicked fast when hooked up with a pair of U320 SCSI drives.
>>
>>
>>
>> ---------------------------(end of broadcast)---------------------------
>> TIP 3: Have you checked our extensive FAQ?
>>
>> http://www.postgresql.org/docs/faq
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: erik.myllymaki@aviawest.com, mark.lewis@mir3.com, vivek@khera.org
Subject: Re: hardare config question
In-Reply-To: <44564C3F.2040609@aviawest.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox