HPE EVA Storage
1748181 Members
3819 Online
108759 Solutions
New Discussion юеВ

Re: File transfer rates on Windows 2003 and EVA 8000?

 
SOLVED
Go to solution
Paul Lessor
Occasional Contributor

File transfer rates on Windows 2003 and EVA 8000?

I have a W2k3 sp2 standard edition with a pair of qlogic 2340 hba's installed.

When I do a file copy from one disk to another the best throughput I can get is 36 MB/s.

I am not sure what performance I should expect out of this transfer. I know that the Fibre is capable of 250 MB/s. I expect some overhead from the OS and the file system, but this is a factor of 8.

I have Microsoft MPIO installed with the HP DSM for EVA 8000. I have ALB enabled and am using SQST. What is the benchmark for disk to disk transfers?

Any comments are appreciated.

Thanks,
10 REPLIES 10
Morten Dalgaard
Occasional Advisor

Re: File transfer rates on Windows 2003 and EVA 8000?

Windows file copy is fairly inefficient.

I'd recommend you to try iometer for benchmarking SAN performance instead.

Use large blocks (like 128kb), with a fairly large Queue size(like 64), and sequential reads if you want raw sustained performance measurements.
Ted Buis
Honored Contributor

Re: File transfer rates on Windows 2003 and EVA 8000?

Tell us some more about the number, size and speed of the disks in your disk group and the size and RAID level of the LUNs you have created. Also, what other activity is happening on the EVA when you are measuring your results? Are you using Business Copy or Continuous Access that could impac performance? Windows can be particularly slow with many small files, so is your file copy from a single large file or many small ones? Also, 2Gb FC is really only about 200MB/s, as there is overhead in the packets. A LUN is primary on one controller and while the second contoller can handle requests for LUNs for which it is not the primary (active-active), it simply passes the request to the primary contoller if it is functioning properly, so static load balancing by alternating LUNs and paying attention to the path from the host to the primary LUN controller is a good approach.
Mom 6
Paul Lessor
Occasional Contributor

Re: File transfer rates on Windows 2003 and EVA 8000?

We have 208 10K 146 Gb disks in our disk group. LUNS are RAID 5. Continuous Access is in use, but not on the destination vdisk. The file copy is a mixture of small and large files ranging from small word docs to 600 MB engineering files.

What I want to know is a simple thing (I think) What kind of performance should one expect when copying files from one Disk to another Disk? Both disks are on the same server. The server has two HBA's with Active Load Balancing and Microsoft MPIO/HP DSM. The storage is EVA 8000. In this scenario what is an acceptable transfer rate. Everyone seems to agree that 36 MB/s is low. Realistically, what should I be expecting? Can someone out there just do a file copy (I use robocopy with no logging and only the /copy:D option) from disk to disk on a windows files server/eva8000 config and tell me what results they get? I would really appreciate that.

Thanks,


Daniel Keisling_2
Occasional Advisor

Re: File transfer rates on Windows 2003 and EVA 8000?

I seem to have the same problem, albeit with HPUX and Linux. I seem to only be able to push about 25-35 MB/sec, and most definitely nothing close to 200MB/sec or above. This is with a pretty light load on an EVA8000 (a couple of servers).

I seem to have everything configured correctly, such as load-balancing, queue depth, write cache enabled, LUNs balanced across controllers, etc.

PLEASE chime in or post any results you may have. I've been fighting with HP Support on what seems like poor performance.
Phillip Thayer
Esteemed Contributor

Re: File transfer rates on Windows 2003 and EVA 8000?

I don't have an EVA8000 to play with but I have dealt with EVA's a bit.

A couple of things here:

First make sure you have installed and are using the HP HBA drivers. If not then you WILL have performance issues with those HBA's.

The 10K drives using VRAID5 will a performance issue. If you want create a LUN with VRAID1 and see if the performance is better. You could then look at migrating data from VRAID5 to VRAID1 or splitting it up between the two types of VRAID LUNS.

Phil
Once it's in production it's all bugs after that.
Hasan  Atasoy
Honored Contributor

Re: File transfer rates on Windows 2003 and EVA 8000?

hi paul ;

if you make small io size you will get high io per sec, if you make high io size ( 228k 256k ) then throughput will increase. als├Д┬▒ it depens on write/read ratio, if you increase write ratio your througput will increase since your io assumed completed after writing to cache... you should use iometer or similar progras to test io instead of copying large file.

Hasan.
Ted Buis
Honored Contributor

Re: File transfer rates on Windows 2003 and EVA 8000?

If your source and destination is on the same Disk Group then you need to consider that you are mixing reads and writes potentially to the same disks which could invovle much head repositioning. For backup considerations, Windows with small files has challenges even getting to what you are seeing, so it isn't necessarily the EVA that is the bottleneck. With RAID 5 there is always a write penalty, so they writing part of your copy would be the limiting factor. How full the file system is can also be a factor in performance. Continuous Access would also consume resources from the EVA controllers, even if that is with a different disk group. The copy in Windows may be more suseptible to latency than some of the other operating systems, or may have something in the code to keep it from saturating an I/O channel. FC SANs do have some extra latency over direct attached storage, so that could be a factor.
Mom 6
Bill Costigan
Honored Contributor
Solution

Re: File transfer rates on Windows 2003 and EVA 8000?

You cannot even consider the speed of the fiber channel, it rarely ever comes into play unless there is some problem with the network (flakey GBIC, cable etc.)

The issue is almost always disks. during a copy, you cannot write the data until you read it. So windows requests a block from the eva. If it's in cache - good, if not the eva has to go get it. The eva has to wait for that disk to complete the read before it can return the block to windows. It doesn't matter how many disks are in the eva, if the data is on one disk, that is the disk that must be read. If the windows OS could request 100 different blocks at the same time, the eva could issue 100 reads from 100 disks at the same time and get 100 blocks in the same time as it takes to get 1. But if the window's OS decides to read 1 block and then write 1 block, the speed would be equal to the read rate of a single disk. The eva trys to be smart about guessing which block the OS will ask for next but if the windows OS is jumpping all over the place, that becomes harder.

The only why to figure out what is really going on is to run perfmon and look at the disk I/Os and response times. I'm guessing the writes are taking less than 1 ms but the reads are taking 4 or so ms.

Also look at the number of bytes /read and the number of reads /sec
glennn
Advisor

Re: File transfer rates on Windows 2003 and EVA 8000?

Hi,

Have you found out what caused your low read throughput? i seem to be experiencing the same problem w/ my newly upgraded eva6100 to xcs6.220. xcs 611o had a known issue w/ respect to its read cache. after my upgrade, my linux machines' read throughput tripled. But my win 2k3 sp2 servers' read throughput halved. I'm thinking i'ts a compatibility issue w/ the hba driver or hp dsm being used.

cheers!