Mirror UX

[Lacrosse]

Can someone tell me roughly what sort of over head I will see on the system when using mirror UX to create multiple copies of my data also what sort of performance increase I will see on reads

[baiju_3 · Accepted solution]

By RAID 1 , mirroring you will not achieve any performance improvements.

For read/write performance Improvment you can Impliment striping (RAID 0 ) , lvcreate command has option to do this ,refer man pages.


Having more number of stripes (disks ) will improve I/O performance .


Thanks,
BL.

[Patrick Wallek]

Are you talking about overhead when initially creating a mirror? Like when you do 'lvextend -m 2 /dev/vg??/lvol?'? Or are you talking about overhead when doing writes to keep the mirrors in sync?

The initial creation of a mirror can take a while and can have some impact on performance, though generally not much.

The impact of doing multiple writes to keep the mirrors in sync will be minimal. The only time I noticed any significant performance degradation was when I was doing some testing of mirroring over a FCIP link simulating going to a remote location.

With regard to read performance, multiple mirrors could actually improve your read time. The read will be done from the mirror with the shortest queue at the time the read is requested.

Hopefully this answers your question.

[Fabio Ettore]

Hi,

doc KBRC00015804 can help you.

Best regards,
Fabio

[Devender Khatana]

Hi,

read from multiple copies will be always faster. Writes may add some overhead but not much. Onlything what will effect it max. will be the access to various mirrors.

All the devices should be of same speed/RPM exactly and should be similarly visible to system.

HTH,
Devender

[James R. Ferguson]

Hi:

There will be some overhead but it will me minimal, certainly compared to the high-availablity you will gain by implementing it.

The biggest overhead you will see is during the initial synchronization of the mirror extents. This is somewhat time-consuming and I/O intensive, of course.

You can control (with tradeoffs) some of this overhead by altering the mirror_write_cache and mirror_consistency attributes during the 'lvcreate' of the mirror. See the manpages for 'lvcreate' for more information.

Regards!

...JRF...
Regards!

...JRF...

[Geoff Wild]

According to the "performance cookbook"

http://h21007.www2.hp.com/dspp/files/unprotected/devresource/Docs/TechPapers/UXPerfCookBook.pdf


"There's a lot of LVM functionality builtin to support High Availability. Options such as
LVM Mirroring (writing multiple times) and the LVM Mirror Write Cache are "antiperformance"
in most cases. Sometimes for read-intensive workloads, mirroring can
improve performance because reads can be satisfied from the fastest disk in the mirror,
but in most cases you should think of LVM as a space management tool â it's not built
for performance. Stephen tells customers "There comes a time when you have to decide
whether you want High Availability or Performance: ya can't have both, but you can make
your HA environment perform better."

Rgds...Geoff

[MarkSyder]

There is indeed overhead when you create the mirror, but for a new filesystem you can save a lot of time thus:

1. create a small lvol/filesystem

2. mirror it

3. extend it.

This is a lot quicker than mirroring a large lvol which contains a lot of data.

Mark Syder (like the drink but spelt different)