Re: IDE x SAS RAID 0 on HP DL 380 G5 P400i controller performance problem

From: Scott Carey <scott(at)richrelevance(dot)com>
To: Daniel Ferreira de Lima <dfl(dot)man(at)gmail(dot)com>
Cc: Greg Smith <greg(at)2ndquadrant(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: IDE x SAS RAID 0 on HP DL 380 G5 P400i controller performance problem
Date: 2010-07-20 22:58:07
Message-ID: D9ED4305-F976-487A-B957-DE0C1A453F86@richrelevance.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

If you are using ext3, your performance on the RAID card may also improve if the postgres xlog is not on the same partition as the data. Otherwise, for every transaction commit, all of the data on the whole partition will have to be sync()'d not just the xlog.

Also, what is the performance difference between all the inserts in one script if you do:

* all your statements in the script
vs.
* first line is "BEGIN;" then all your statements, then "COMMIT;" at the end?

If these two are about the same on your old IDE drive, then your I/O stack (file system + OS + hardware) is lying to you about fsync(). The latter should be a lot faster on your RAID card if write-back caching is not on.

On Jul 19, 2010, at 12:53 PM, Daniel Ferreira de Lima wrote:

That said, a look into the write-caching+BBU policy on your controller is worthwhile. If you're running this application successfully on some hardware but not others, that could be a source for the difference.

I think it's really a BBU/BBWC problem.
The tests that we made in the lab with HP Blade G5 (G6 doesn't support kernel version 2.4) turning the battery off show us the 'same' performance of the "pizza-box" HP DL 380 G5.. an old joke. 40 secs to 2000 insertions: like a chariot.

We're finding the cache expansion and batteries (and.. why it's not default???).

I think that this thread is now finished.

Thanks!
--
Daniel Ferreira

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message kuopo 2010-07-21 03:51:44 Re: how to handle a big table for data log
Previous Message Pavel Stehule 2010-07-20 19:39:04 Re: potential performance gain by query planner optimization