Bug 640874

Don

I actually took your paragraph from the guide and added content to it in the Hardware section. Here is the modified section.

Hardware


Every I/O sub-system has limits on how much data it can process per second. If your system hosts an application that needs to perform many small (ranging from 2k to 8k) I/Os, typically in transaction processing system, it is recommended that you choose storage subsystems that have a fair amount of controller cache, high-speed disks (i.e. 15Kbps or higher, typically SAS or solid-state disks), and low-latency connection to storage. Each of these hardware recommendations are directly responsible for processing IOs at a high rate but they all come at a steep cost. That is why planning at this stage takes out a lot of trouble that can result if they are identified as bottlenecks at the production stage because changing/upgrading hardware is a diffcult time consuming process. Each of these items are explained in detail 
 
    Controller Cache - This is the cache on the storage controller similar to physical memory (RAM) on a server and is one of the most expensive pieces in the storage controller infrastructure. In most cases the controller cache is battery backed and in these situations, once the data is handed off to the controller cache the server considers the IO as completed. The amount of cache on the controller can range anywhere from 1G to 64G or higher depending on the storage vendor. The information on the amount of cache and rate at which the controllers can process the IO should be the determining factor in deciding which hardware to choose. Most vendors will supply this information under NDA.

    High speed disks - This is pretty self-explanatory. The cost of the disk is directly proportional to the speed of disk. 

    Low-latency connection - The most common external storage are based on Fibre channel, ethernet or PCI direct connect. The rate at which IOs are processed depends on the connectors used. For e.g. Network based storage can have significant latency overhead as each packet needs to be processed but there are special network cards that offload the network layer processing from the OS to the hardware to reduce the latency. 

If the I/Os are in the larger block range, typically in Data processing (BI) type environments, stripping across controllers to take advantage of collective bandwidth is recommended. In data processing environments, the storage needs can be quite high (1 TB or higher) so the low-latency is definitely worth considering, followed by the disk speed. As most of these environments are read based, the controller cache can be scaled back to the lower end. 


Under the operating system section,

Not sure what you mean by the comment "characterization=profile?"

The comments that I added are for the IO vs Storage section. This section on IO alignment looks good.

thanks Sanjay, revised the text accordingly. please review:

http://documentation-stage.bne.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/main-io.html#s-io-planning

as for your clarification on "characterization", i was referring to this statement:

<quote>
There are many tools that can be used to do low-level I/O subsystem characterization.
</quote>

By "characterization" did you mean "profiling"?

Yes. I did mean profiling.

The hardware section in the document is still the old one. Please take a look at the modified section above which has responses to some of your original comments in the document and change it accordingly.

Created attachment 479125 [details]
pdf build as of Feb 17, 2011

i don't know why that is. i'll look into it; in the meantime, i've attached a PDF build to this bug for your perusal.

(In reply to comment #12)
> The hardware section in the document is still the old one. Please take a look
> at the modified section above which has responses to some of your original
> comments in the document and change it accordingly.

Laura

I found a few of the edits that I suggested are not in the document. In the following sentence, please replace the word "light" with "small". The word "small" used here is correct in the context because it refers to the IO size and not the IO rate.

----------
Hardware

Every I/O sub-system has limits on how much data it can process per second. If
your system hosts an application that needs to perform many "small" (ranging from
2k to 8k) I/Os, typically in transaction processing system, it is recommended
that you choose storage subsystems that have a fair amount of controller cache,
high-speed disks 
---------------

The first bullet in this section needs to be changed


------------
 The amount of cache on the controller ranges from 1G to 64G (or higher), depending on the storage vendor. The most important factors to consider when choosing controller cache hardware are:

    *  The amount of cache should be the determining factor in deciding which hardware to choose.
    *  The rate at which the controllers can process I/O transactions 

---------------


Other than these the documents looks good.

Thanks, Sanjay! I've changed:
 * light --> small
 * The amount of cache should be the determining factor in deciding which
hardware to choose. --> The amount of cache, and

Please take one more look so that you have final signoff on this content, and then we're done. :) Thanks!

Thanks Laura. 

Those are the only changes I had. We are good to go.

Verified based on c#18 in Red_Hat_Enterprise_Linux-Performance_Tuning_Guide-6-en-US-1.0-28