large window LUN performance

[richardl]

IHAC running NetApp FC-SAN and have below observations:

Scenerio 1:

> create 1 x 4TB LUN (SATA with 16 disks aggr.), using window basic disk (GPT)

> application write performance is horrible, around 30 to 40MB/s only

> application read performance is around 45MB/s

Scenerio 2:

> create 2 x 2TB LUN (SATA with 16 disks aggr., same aggr like above), using window basic disk (MBR)

> then create a 4TB LUN using RAID0 on above

> application write performance now is around 100MB/s

> application read performance is similar to above

They are running FAS3140,  using same host server for above test.

They like to know any reason why above happened,  or alternatively, do we have any documentation talk about the best practice to create large window LUN (target ~10TB single LUN).

Any input is highly appreciated.

[cedric_renauld]

Hi,

Maybee a stupid question .... but ....

For th efisrt test, have you "mark" the LUN with Windows GPT style ?

[amiller_1]

So...I'm not sure if this totally applies but I found at a previous site (where I worked for quite a few years actually) that AIX in particular had very different performance characteristics when given (1) LUN vs. (10) LUNs and a single filesystem on top (where the total space was the same and all LUNs were in the same volume actually).

This happened both with FC & iSCSI connectivity -- it basically seemed like inside AIX there was a max throughput (or maybe requests) per LUN. Making one filesystem across all those LUNs (no higher failure possibility to be honest since all the LUNs come from the same volume/aggregate).

[radek_kubka]

Some bells were ringing before, but I got it now in detail!

It is probably due to IO queue length per LUN which is defined by HBA:

Emulex - 30 default per LUN (max of 128)
Qlogic - 32 default per LUN (max of 128)

These can be changed via HBA utilities, so I guess a single LUN with say 60 IOs queue length should give roughly the same results as a couple of them with 30 queue length each.

Regards,
Radek