EVA 3000 Performance

[Virgilio Santiago]

Hi to all

I am currently experiencing a similar problem as described in the following thread:

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=774143

Unfortunately, I discovered this discussion thread when my 2 evas are already in production. Now I find myself with worse performance than the obsolete hardware I just replaced.

[Victor_101]

Hi guys .
Any updates ??? I have already contacted HP ie. through the guys who sold it to me.. but to no avail...

Please help.. ASAP

[Dave La Mar]

Victor -
We just went through an analysis on our 5000. One of the recommendations was changing the kernel parm scsi_max_qdepth from 8 to 12.
This can also be changed on a device level rather than a global kernel parm. As a matter of fact we are tracking the queueing today for a 24 hour period. Then next week we will change the value using scsictl command and track on the that Tuesday. In onther words, our bottle neck was in disk queueing. Since this type of change can affect service time as well, we are tracking service time over those two days as well.
In looking at your output, it does seem a bit low. I would guess you need to turn on other metrix for your report. i.e. (DISK):BYDSK_AVG_SERVICE_TIME and
(DISK):BYDSK_REQUEST_QUEUE
At least you can eliminate these two factors.

Will be interested to hear the outcome as it seems you have company on this issue.

Regards,

dl

[Victor_101]

Hi Dave,
I did get this recommendation from HP last month to Change SCSI_MAX_DEPTH parameter from the default 8 to 64. I did get an increase in performance by 30% , but not really the figures I was looking for...
reading a 5 GB file completes in 45 secs .. but writing which originaly was taking 2min15 secs came down to 1min50secs... to u see.. still a vast difference in speeds...
is HP looking into the matter as a probable bug?? maybe we need to get their attention with regard to this ..
i will do so at my end.. at the same time.. with regard to the matter above.. i did ask them if i increase the above Kernel parameter more ( max allowed =255) would if get better.. ??? no reply yet..

with regard to "
In looking at your output, it does seem a bit low. I would guess you need to turn on other metrix for your report. i.e. (DISK):BYDSK_AVG_SERVICE_TIME and
(DISK):BYDSK_REQUEST_QUEUE "
what do you mean ? where can i monitor these values ? i added all the available options under the Evaperf tools to be monitored... am I missing something ??

how are ur tests goin for u now ?? must be a couple of hours since u started i guess

victor

[Dave La Mar]

Victor -
The monitoring I am using is with Glance in Adviser mode.
I am not sure of the equivalent metric syntax in EVAPerf, but seems like you have the user guide.
In any event, to check the queueing and service time using glance, the metrics are:
bydsk_request_queue
bydsk_avg_service_time
Neither is case sensitive and can be all caps.
The report runs from the HP server.
I'm attaching a down and dirty script for capturing the values by disk, at 10 second intervals.
1. We started the script yesterday at 14:00 and it will end at 13:00 today.
2. We will then look at the data and adjust the queueing by disk using the scsictl command.
3. On Tuesday fo next week we will run the script for the same time period and compare the results.

Excuse the roughness of the script, but is is only for this temporary task.

Will follow your thread.
I was afraid to raise the kernel parm as high as you did. A 30% increase is significant, though in the context of poor performance, this is not always true. By raising it that much, you might ask HP what else was affected.
We were told to watch and monitor the service time because increasing the queue depth too much would likely result in higher service time.

In the sample output attached you will see disk 255/0.0.5 doing queueing at that given snapshot.
My initial look at our current data capture seems to indicate service time variation is more prevalent than queueing. I'll be running all this by HP.

Best of luck with this.

-dl

[Dave La Mar]

Victor -
Thought I would pass on the update of our data collection for the queue depth change. As it turns out, HP has agreed that no change in our environment is necessary. Our periods of disk queueing were small and varied over different disks.
Wish I had more to offer, but it appears our environments must differ too much from yours.
As before, best of luck on your performance challenge.

Regards,

dl