> WRT seek performance, we're doing 2500 seeks per second on the
Sun/Thumper on 36 disks.
Luke,
Have you had time to run benchmarksql against it yet? I'm just curious
about the IO seeks/s vs. transactions/minute correlation...
/Mikael
---(end of broadcast)---
On 8/3/06, Luke Lonergan <[EMAIL PROTECTED]> wrote:
Merlin,
> moving a gigabyte around/sec on the server, attached or no,
> is pretty heavy lifting on x86 hardware.
Maybe so, but we're doing 2GB/s plus on Sun/Thumper with software RAID
and 36 disks and 1GB/s on a HW RAID with 16 disks, all SA
Merlin,
> moving a gigabyte around/sec on the server, attached or no,
> is pretty heavy lifting on x86 hardware.
Maybe so, but we're doing 2GB/s plus on Sun/Thumper with software RAID
and 36 disks and 1GB/s on a HW RAID with 16 disks, all SATA.
WRT seek performance, we're doing 2500 seeks per s
On 7/18/06, Alex Turner <[EMAIL PROTECTED]> wrote:
Remember when it comes to OLTP, massive serial throughput is not gonna help
you, it's low seek times, which is why people still buy 15k RPM drives, and
why you don't necessarily need a honking SAS/SATA controller which can
harness the full 1066MB
According to
http://www.pcguide.com/ref/hdd/perf/raid/concepts/perfStripe-c.html, it seems
to be the other way around?
("As stripe size is decreased, files are broken into smaller and smaller
pieces. This increases the number of drives
that an average file will use to hold all the blocks contain
--Original Message-
> >From: Scott Marlowe <[EMAIL PROTECTED]>
> >Sent: Jul 18, 2006 3:37 PM
> >To: Alex Turner <[EMAIL PROTECTED]>
> >Cc: Luke Lonergan <[EMAIL PROTECTED]>, Mikael Carneholm <[EMAIL PROTECTED]>,
> >Ron Peacetree <[EMAIL PR
c: Luke Lonergan <[EMAIL PROTECTED]>, Mikael Carneholm <[EMAIL PROTECTED]>,
>Ron Peacetree <[EMAIL PROTECTED]>, pgsql-performance@postgresql.org
>Subject: Re: [PERFORM] RAID stripe size question
>
>On Tue, 2006-07-18 at 14:27, Alex Turner wrote:
>> This is a great
On Tue, 2006-07-18 at 14:27, Alex Turner wrote:
> This is a great testament to the fact that very often software RAID
> will seriously outperform hardware RAID because the OS guys who
> implemented it took the time to do it right, as compared with some
> controller manufacturers who seem to think i
This is a great testament to the fact that very often software RAID will seriously outperform hardware RAID because the OS guys who implemented it took the time to do it right, as compared with some controller manufacturers who seem to think it's okay to provided sub-standard performance.
Based on
Title: Re: [PERFORM] RAID stripe size question
Mikael,
On 7/18/06 6:34 AM, "Mikael Carneholm" <[EMAIL PROTECTED]> wrote:
> However, what's more important is the seeks/s - ~530/s on a 28 disk
> array is quite lousy compared to the 1400/s on a 12 x 15Kdisk array
I&
> This is a relatively low end HBA with 1 4Gb FC on it. Max sustained
IO on it is going to be ~320MBps. Or ~ enough for an 8 HD RAID 10 set
made of 75MBps ASTR HD's.
Looking at http://h30094.www3.hp.com/product.asp?sku=2260908&extended=1,
I notice that the controller has a Ultra160 SCSI interfac
>From: Alex Turner <[EMAIL PROTECTED]>
>Sent: Jul 18, 2006 12:21 AM
>To: Ron Peacetree <[EMAIL PROTECTED]>
>Cc: Mikael Carneholm <[EMAIL PROTECTED]>, pgsql-performance@postgresql.org
>Subject: Re: [PERFORM] RAID stripe size question
>
>On 7/17/06,
On 7/17/06, Ron Peacetree <[EMAIL PROTECTED]> wrote:
-Original Message->From: Mikael Carneholm <[EMAIL PROTECTED]>>Sent: Jul 17, 2006 5:16 PM>To: Ron Peacetree <
[EMAIL PROTECTED]>, pgsql-performance@postgresql.org>Subject: RE: [PERFORM] RAID stripe size q
-Original Message-
>From: Mikael Carneholm <[EMAIL PROTECTED]>
>Sent: Jul 17, 2006 5:16 PM
>To: Ron Peacetree <[EMAIL PROTECTED]>, pgsql-performance@postgresql.org
>Subject: RE: [PERFORM] RAID stripe size question
>
>>15Krpm HDs will have average access
Mikael Carneholm wrote:
Btw, here's the bonnie++ results from two different array sets (10+18,
4+24) on the MSA1500:
LUN: DATA, 24 disks, stripe size 64K
-
Version 1.03 --Sequential Output-- --Sequential Input-
--Random-
-P
>Unless I'm missing something, the only FC or SCSI HDs of ~147GB capacity are
>15K, not 10K.
In the spec we got from HP, they are listed as model 286716-B22
(http://www.dealtime.com/xPF-Compaq_HP_146_8_GB_286716_B22) which seems to run
at 10K. Don't know how old those are, but that's what we go
On 7/17/06, Mikael Carneholm <[EMAIL PROTECTED]> wrote:
>> This is something I'd also would like to test, as a common>> best-practice these days is to go for a SAME (stripe all, mirroreverything) setup.>> From a development perspective it's easier to use SAME as the
>> developers won't have to thin
On Mon, Jul 17, 2006 at 09:40:30AM -0400, Ron Peacetree wrote:
> Unless I'm missing something, the only FC or SCSI HDs of ~147GB capacity are
> 15K, not 10K.
> (unless they are old?)
There are still 146GB SCSI 1rpm disks being sold here, at least.
/* Steinar */
--
Homepage: http://www.sesse
>From: Mikael Carneholm <[EMAIL PROTECTED]>
>Sent: Jul 16, 2006 6:52 PM
>To: pgsql-performance@postgresql.org
>Subject: [PERFORM] RAID stripe size question
>
>I have finally gotten my hands on the MSA1500 that we ordered some time
>ago. It has 28 x 10K 146Gb drives,
>
Unless I'm missing something,
>> This is something I'd also would like to test, as a common
>> best-practice these days is to go for a SAME (stripe all, mirror
everything) setup.
>> From a development perspective it's easier to use SAME as the
>> developers won't have to think about physical location for new
>> tables/indice
Hi, Mikael,
Mikael Carneholm wrote:
> This is something I'd also would like to test, as a common best-practice
> these days is to go for a SAME (stripe all, mirror everything) setup.
> From a development perspective it's easier to use SAME as the developers
> won't have to think about physical lo
>I think the main difference is that the WAL activity is mostly linear,
where the normal data activity is rather random access.
That was what I was expecting, and after reading
http://www.pcguide.com/ref/hdd/perf/raid/concepts/perfStripe-c.html I
figured that a different stripe size for the WAL s
Hi, Mikael,
Mikael Carneholm wrote:
> An 0+1 array of 4 disks *could* be enough, but I'm still unsure how WAL
> activity correlates to "normal data" activity (is it 1:1, 1:2, 1:4,
> ...?)
I think the main difference is that the WAL activity is mostly linear,
where the normal data activity is rat
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Michael
Stone
Sent: den 17 juli 2006 02:04
To: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] RAID stripe size question
On Mon, Jul 17, 2006 at 12:52:17AM +0200, Mikael Carneholm wrote:
>I have final
With 18 disks dedicated to data, you could make 100/7*9 seeks/second (7ms av seeks time, 9 independant units) which is 128seeks/second writing on average 64kb of data, which is 4.1MB/sec throughput worst case, probably 10x best case so 40Mb/sec - you might want to take more disks for your data and
On Mon, Jul 17, 2006 at 12:52:17AM +0200, Mikael Carneholm wrote:
I have finally gotten my hands on the MSA1500 that we ordered some time
ago. It has 28 x 10K 146Gb drives, currently grouped as 10 (for wal) +
18 (for data). There's only one controller (an emulex), but I hope
You've got 1.4TB as
On Mon, Jul 17, 2006 at 12:52:17AM +0200, Mikael Carneholm wrote:
> Now to the interesting part: would it make sense to use different stripe
> sizes on the separate disk arrays? In theory, a smaller stripe size
> (8-32K) should increase sequential write throughput at the cost of
> decreased positio
We have a production server(8.0.2) running 24x7, 300k+ transactions per day.
Linux 2.6.11 / JFS file system.
No problems. It works faster than ext3.
> Alex Turner wrote:
>
> > I would also recommend looking at file system. For us JFS worked
> > signifcantly
> > faster than resier for large r
I have found JFS to be just fine. We have been running a medium
load on this server for 9 months with no unscheduled down time.
Datbase is about 30gig on disk, and we get about 3-4 requests per
second that generate results sets in the thousands from about 8am to
about 11pm.
I have foudn that JFS
Alex Turner wrote:
> I would also recommend looking at file system. For us JFS worked
> signifcantly
> faster than resier for large read loads and large write loads, so we chose
> JFS
> over ext3 and reiser.
has jfs been reliable for you? there seems to be a lot of conjecture about
inst
I have benched different sripe sizes with different file systems, and the perfmance differences can be quite dramatic.
Theoreticaly a smaller stripe is better for OLTP as you can write more
small transactions independantly to more different disks more often
than not, but a large stripe size is goo
Typically your stripe size impacts read and write.
In Solaris, the trick is to match it with your maxcontig parameter. If
you set maxcontig to 128 pages which is 128* 8 = 1024k (1M) then your
optimal stripe size is 128 * 8 / (number of spindles in LUN).. Assuming
number of spindles is 6 then y
Hi Everybody!
I've got a spare machine which is 2xXEON 3.2GHz, 4Gb RAM
14x140Gb SCSI 10k (LSI MegaRaid 320U). It is going into production in 3-5months.
I do have free time to run tests on this machine, and I could test different
stripe sizes
if somebody prepares a test script and data for that.
On Tue, Sep 20, 2005 at 10:51:41AM +0300, Michael Ben-Nes wrote:
I must admit im a bit amazed how such important parameter is so
ambiguous. an optimal strip size can improve the performance of the db
significantly.
It's configuration dependent. IME, it has an insignificant effect. If
anything
Hi
John A Meinel wrote:
bm\mbn wrote:
Hi Everyone
The machine is IBM x345 with ServeRAID 6i 128mb cache and 6 SCSI 15k
disks.
2 disks are in RAID1 and hold the OS, SWAP & pg_xlog
4 disks are in RAID10 and hold the Cluster itself.
the DB will have two major tables 1 with 10 million rows
bm\mbn wrote:
> Hi Everyone
>
> The machine is IBM x345 with ServeRAID 6i 128mb cache and 6 SCSI 15k
> disks.
>
> 2 disks are in RAID1 and hold the OS, SWAP & pg_xlog
> 4 disks are in RAID10 and hold the Cluster itself.
>
> the DB will have two major tables 1 with 10 million rows and one with
> 100
36 matches
Mail list logo
