How Important is Stripe unit size ? 1

[JohnBates]

Hi -

Probably a question for the IBM Disk & RAID Solutions forum but it doesn't get as much traffic as this forum.

On my new xSeries server with 4 SCSI 18 GB disk drives, I have configured RAID 5. I accepted the default stripe size of 8kb.

This server will run a shipping system - lots of I/O. Not much printing. The record length of recs in each table is fairly small 70 bytes or so.

A couple of questions:
1) how is it possible to accurately decide whether the stripe unit size should be 8kb, 16, 32 or 64 to get the best performance?

2) How much of a performance hit will the server have if I should have chosen for ex. 32kb rather than 8kb?

These may not even be fair questions... it just seems like there is a lot of "guesswork" in determining the stripe size.

Thanks, John

 

[bjverzal]

I doubt that you'll see any change. All this refers to is the amount written to a disk before the next stripe is written to the next disk.

Don't fret about this parameter.

BV

 

[catorze]

From the IBM RedBook, "The selection of stripe size affects performance. In general, the stripe size
should be approximately as large as the median disk I/O request size generated by your server applications.
If the stripe size is set too small, a performance degradation occurs when a server application requests data that is larger than the stripe size, because two or more drives must be accessed for the I/O request. Ideally, only a single disk I/O occurs for each I/O request. Alternatively, selecting too large a stripe size can reduce performance because the system is not making best use of the multiple drives in the array. It can also be a problem with RAID-5 in particular, where additional stripe
units must be read to calculate a checksum during writing. Use too large a stripe, and extra data must be read each time the checksum is updated."

 

[bjverzal]

I understand this. From a logical perspective, there be a performance degradation. However, with a 10,000 RPM drive and 320MB/sec SCSI speeds, will you really see it ?

Granted, if you know the size of you I/O, you might be able to calculate stripe size, but consider that there is cache on the drive, in the system kernel and possibly on the adapter card. Even though you write to disk, you are probably writing to a cache somewhere, and it will be flushed to disk later.

All these factors work together and I still believe ultimately you won't see too much of a difference, unless the system gets *really* busy.

BV

 

[catorze]

Depending on what you are using the server for, you may see it. If it's the all-in-one server for a small shop, probably not. If it's the database server for an enterprise, handling a couple of million transactions per hour, you will definitely see it. Which is why there is a default setting, the option to change it, and the documentation to explain the logic behind the value. In an imperical scale, disk i/o (the actual arm and head moving up and down the platter to write 0s and 1s) has been and always will be the limiting factor (which is why more drives in a RAID5 configuration are better - more writing heads). The original question was one more of optimization theory, not of the degree of performance improvement. If you have tons of CPU and RAM, you may never see the inefficiencies written into software, but they are still there. BTW, you forgot to include CPU caches (L1, L2, and possibly L3), RAM (and swap space), and that the ServeRAID controller definitely has cache (and available battery backup on most).

 

[JohnBates]

Here is alittle more about the specs:

Dual processor 2.6 GHz

1.5 GB RAM

Hundreds of thousands of transactions per hour (but less than a million I'm sure)

Thanks for all the opinions. John

 

[bjverzal]

Define a transaction. How many I/O's per transaction?

600,000 transactions / hour = 10,000 transactions / minute = 166.67 transactions / second. Not a great deal of I/O, assuming 1 transaction = 1 I/O.

If however, a transaction is:
A complex lookup on several tables with joins
A lookup to another table
A sort
A write
then we're talking lots of I/O per second. But again, if it is SCSI-320 with 10K RPM drives, this will all be done fairly quickly.

Remember, if this is handled via a adapter card, then the I/O is handled by the processor on the RAID circuit. Therefore, it is offloaded from the CPU.

But again - with filesystem caches and cache on the RAID card, I think we're splitting hairs.

BV

 

[JohnBates]

Most of the writes are writing 1 record/row each time. But the reads usually query tables having less than 2000 rows.

Merge replication is involved though, so every update/delete/insert results in the same table getting updated on the alternate server.

I agree with you, BV. Dont think this is worth worrying about.

Thanks for everyones opinion. John