- Community Home
- >
- Storage
- >
- Entry Storage Systems
- >
- Disk Enclosures
- >
- Re: EVA 3000 Performance
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-26-2005 01:38 AM
тАО07-26-2005 01:38 AM
EVA 3000 Performance
We are primarily worried about the Read speeds.The 80 MB is reached after several repetition of the same process ( can be attributed to Cache?)
As such , we are looking for an alternate means of monitoring the actual throughput to validate if these speeds are true and acceptable since the Data Sheet of the EVA 3000 speculates the Maximum Sustained Throughput to be 335MB/sec and we are currently just at 1/5th those speeds. Are there any kernel paramaters in place that are limiting these speeds since we even monitored the Port Utilization on the SAN Fabric switches and those too are not peaking to maximum.
The read speeds are our main concern , the 80 MB/sec read is achieved by repeating DDs , hence probably attributed to Cache. The 1st time a read is performed on a 5 GB file we get not more than 40 MB/sec. if the DD is for a larger file, in our case 350GB of Raw data files as one backup, we get worse figures and the cache will not help
We have an Oracle RAC 2 node CLuster of Rp5470s connected via 2GB FC to an EVA 3000 with 26*73GB disks (15k rpm) with Vraid1.
Is the Raid level a problem ?
What tools can I use if I need a better measurement of performance?
We are currently just using DD to measure throughtput.
Cheers
Victor
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-26-2005 04:32 AM
тАО07-26-2005 04:32 AM
Re: EVA 3000 Performance
There are some filesystem parameters that you should tune to get best performance, this parameters are the journaling options, the block size, the sparse super, stripe size. Use the mkfs and tune2fs options to adjust these parameters.
You can use dd on the raw devices to check the impact that the filesystem is having in your tests.
Use iostat to check the bps and tps on the disks, you need to have installed systat tools.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-26-2005 08:15 AM
тАО07-26-2005 08:15 AM
Re: EVA 3000 Performance
So if the array is doing read-ahead to try to get the blocks into cache before you get around to asking for them, the array can only fill the cache as fast as the disk can provide data.
Assume a 15K disk can do 200 reads per second. You have 26 disks doing 200 reads per second and 8196 bytes per read.
26 * 200 * 8196 = 42.5MB/sec.
That means the data is coming into cache at 42.5MB /sec so if cannot go out any faster.
Note: writes would be half of that because with raid 0/1. each write has to go to 2 disks.
When HP [or anyone else] publishes I/O rates they typically use an array with the maximum number of disks. With enough disks (assuming the load is balanced) the next bottleneck may be the fiber channel or controllers.
FATA drives will be slower than the 15K
I don't know what drive technology you were testing. The I/O rate per disk will depend on how localized the data is on the disk. I've seen some 15K drives approach 500 I/Os per second and drop to about 120 when the data is scattered.
In any case, the numbers you are seeing are diectly related to the number and speed of the disks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-26-2005 05:25 PM
тАО07-26-2005 05:25 PM
Re: EVA 3000 Performance
were running 26 FC disks in 2 enclosures that can hold a maximum of 28 disks. were running them over 2 GB FC. and while monitoring the port utilisation on the SAN switches (brocade) ,we see that the traffic is getting evenly distributed across the ports.. hence load balancing is working.. but to what effect..
main question is .. is this the maximum speeds?? or does the eva perform faster?
if it should. then i will log a call with HP and ask them solve it..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-27-2005 09:16 PM
тАО07-27-2005 09:16 PM
Re: EVA 3000 Performance
I am attaching the EVAPerf statistics from the HOST PORT UTILISATION. Can anybody interpret?
Thanks
Attachment is Excel sheet
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-28-2005 01:39 AM
тАО07-28-2005 01:39 AM
Re: EVA 3000 Performance
"The 80 MB is reached after several repetition of the same process ( can be attributed to Cache?) "
Yes, maybe is filesystem cache.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-28-2005 02:17 AM
тАО07-28-2005 02:17 AM
Re: EVA 3000 Performance
Arrays try to maximize the efficiency of each I/O by trying to transfer the most data per I/O (concatenating I/Os) or doing them at times when the host isn't waiting for them. (read ahead, and write caching)
The bottom line is 28 disks can only do so many I/Os and I'm sure you are hitting this limit. Adding more disks should increase your throughput.
It's not that the eva is slow, It's just sitting around waiting for the disks to complete their I/Os.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-29-2005 08:05 AM
тАО07-29-2005 08:05 AM
Re: EVA 3000 Performance
I suspect you may need something with a little more horse power. An XP with more disks would probably be a better match.
It will have more cache, more I/0, more fibers,real active/active controllers, holds allot of disks.
If you do go this route carve small luns and make say a meta 3 that is 13 gigs in size. Have hp preaddress the luns so they are spread evenly accross the controllers for performance, not down the fibers. Allocate as many disks in the correct lun order to your vg. If you use bcvs put em inside the spindle.
On your eva. Talk to oracle and make sure your memory/swap and kernel parameters, and system resources are not an issue.
I would create multiple luns the same size. Do a Lvcreate -L size with -i -I
use a stripesize of 1024 oracle likes that
adn the number of disks you create
This should help you by allowing more cache per lun and lowering the probability that the same lun is being hit by to different IO requests at the same time which creates a random search. This is bad because your caching and prefetch goes to hell. Hoepfully the EVA is smart enough to do this at lun level vs disk. The other problem you are going to be fighting with this design is it decides where its putting the data in the disk group and you have no control over it whether the built in intelligence is right or wrong.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-03-2005 03:42 AM
тАО08-03-2005 03:42 AM
Re: EVA 3000 Performance
As others are saying, performance (specifically, multithreaded total throughput) will go way up when you add disks.
Can anybody actually verify (or comment on) Jeff's idea of using many little LUNS and striping them at the host level with an EVA?
I'm skeptical, but interested in discussion.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-03-2005 05:19 AM
тАО08-03-2005 05:19 AM
Re: EVA 3000 Performance
I have a similar, strange performance problem with one of our EVA3000 array.
- General performance is poor.
- Write (restore) is faster then Read (backup).
- A EVA 3000 with 8 disks performs better then a system with 56 disks.
You can find more details about my problem here:
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=888255
I have logged a support case to HP for this problem but, not yet got any useful feedback.
About striping LUNs:
Assuming you are using only 1 disk group, it is no idea (for performance reasons) to stripe LUNS. As I have found in the EVA documentation, it is possible to get the specifyed throughput, using just one single LUN.