Disk I/O Performance of the simultaneous process

[John Jayaseelan]

Hi,

K370 server installed with HP-UX 11.00.

There are 2 progress database processes extracting a huge amount of data from the mirrored disks (The processes can read data from either of the disks without blocking each other) and writing into a LV on a single disk.

I guess there might be a disk bottlenecks during the write. Is that right? Can this write bottle neck can be overcome by extending this LV onto another disk so that 2 to processes can write without any disk I/O issues?

Thanks
John Jayaseelan

[Uwe Zessin]

John,
I don't know LVM very well, but if you can create a set of striped mirrors (2 mirrorsets and a stripeset on top to combine both mirrors into a larger disk) you can easily enhance your I/O capacity. The striping makes sure that half the I/Os go to each mirror.

If you just 'append' another mirror to the volume group, my guess is that it will not be that effective, because the LV is still stored on the first mirror.

[Vladimir Vybiral_1]

Hello,
the bottleneck might easily be in the disk subsystem, depending on the number of spindles (disks) You have in the mirror. Assuming a disk can handle approximately 180 IOs per second physically, not accounting for any cache, You can easy calculate how is Your throughput, based on the IO size. Database IOs are in the reach of 4-16kBytes, typically, so this would give You 4x180 kB to 16x180 kB througput performance per disk. Having 2 disks in a mirror, You have Your maximum at 2x4x180=1240kB/s for 4kB IO to 2x16x180=5760kB/s for 16kB IO.
Note that this is for 100% read operation, best case. Adding new disks to the mirror for striping will increase Your IO throughput linearly.

best regards

Vladimir

[David Child_1]

John,

The short answer is yes.

For the most part Vladamir is correct. One point I would disagree on is that when you have a mirrored pair you won't get double the max IOPS because you have to write to both disks anyway (unlike the read operation where only one disk need return the data).

The bottleneck issue does depend a lot on your block sizes and as already mentioned databases tend to use smaller block sizes so IOPS would tend to be your bottleneck. Of course since you are reading in a lot of data and writing it back out there are other things to consider.

By putting two disks in your logical volume and striping it across them should help reduce the bottleneck as this will give you 2xIOPS over 1 disk. Preferrably these two disks would be on separate controllers in case there is contention there.

David

[John Jayaseelan]

Hi,

Thanks for all the response. Let me explain in detail.

The 2 db processes are to be started after office hrs when the system is not used.

The LV from where the huge amount of data to be read continuously exists in a 17GB disk and mirrored onto another 17 GB disk.

The read data is written on to a LV exists on another 8 GB physical disk.

The question is, there might be an issue during the write because 2 processes trying to write huge amount of data onto a singe disk continuously.

Is it going to improve the write performance if the LV where the write is done is extended on to another physical disk?

Thanks

[Uwe Zessin]

If this is a pure single-stream write with short I/O length, then the answer is: NO :-(

The reason is that if the system waits for a single I/O to complete it does not matter if the next I/O goes to the same or a different physical disk. Any disk is idle anyway after the previous I/O has finished.

[Uwe Zessin]

Oh, wait! You wrote you have two database writers, right? Somehow I just missed this :-(

In that case, yes, a second disk gives additional performane if the file (system) is truly spread over both disks (with striping, for example).

[John Jayaseelan]

Hi,

The file system is not stripped. The LV for the FS is mirrored onto another physical disk.

Thanks

[Uwe Zessin]

Is this what you have called the 8GB disk?

So 17GB (2xread) -> 8GB (2xwrite)

17GB = 2 disk mirror set

8GB = currently single disk

As has already been written: you will very likely not get a speed improvement from making the 8GB a mirror if the current disk is already maxed-out with I/Os.

Host-based mirroring is often a synchronous operation. In that case your performance can even drop, because the I/O can only be reported as finished when both disks have written the data to the platter.