cancel
Showing results for 
Search instead for 
Did you mean: 

scsictl & scsi_max_qdepth

 
SOLVED
Go to solution
ManojK_1
Valued Contributor

scsictl & scsi_max_qdepth

Hi,

We are having HP Unix 11.23 is running on HP Integrity servers which all are connected to SAN. Some servers are rx6600 having internal SAS Disks and some are rx7640 having internal SCSI Disks.

scsi_max_qdepth is given as 8. One of my colleque told me that Increasing scsi_max_qdepth will make performance degradation for Internal disks (SAS & SCSI) and it is only intended for luns which are presented through SAN.

I know through scsictl command i can change the respective luns queue_depth. If i change the value to 64 through scsictl command will it work as scsi_max_qdepth kerenel parameter is still 8.

Manoj K
Thanks and Regards,
Manoj K
7 REPLIES
Florian Heigl (new acc)
Honored Contributor
Solution

Re: scsictl & scsi_max_qdepth

hi,

whatever value you set with scsictl only affects the single lun in question, so it'd be perfectly fine to set it for SAN luns to assume that the SAS disks will be unaffected.

That aside - I usually check with the vendor documentation, i.e. some EMC Midrange arrays only supported a value of 128, and most older SCSI disks only support a queue depth of 31.

8 is a "safe default" for disks from the 4.3GB era and I can't understand why it should DEGRADE local disk performance, usually I experience the very opposite - a slight performance increase and also load decrease. One of the current SAS disks selling points over the SATA counterparts is the extended queue depth and the performance benefits thereof!

In any case always REALLY check the vendor recommended values and don't ever run the disk with a higher depth than supported or you will be generating a lot of error messages in the STM logfiles.
yesterday I stood at the edge. Today I'm one step ahead.
Olivier Masse
Honored Contributor

Re: scsictl & scsi_max_qdepth

If I recall correctly, scsictl will do what you want, i.e. it will set the queue depth for only one disk at the time and not the whole system, and override scsi_max_qdepth. In any case, don't change it with SAS disks as I read once that going over 8 can cause trouble with the built-in MPT SAS controller.

However, with scsictl the change is not persistent across reboots. So you need to write a startup script that will do the scsictl at each boot.

Olivier.

ManojK_1
Valued Contributor

Re: scsictl & scsi_max_qdepth

I will check up with the HP and let you know there suggestion and recommendation.

Manoj K
Thanks and Regards,
Manoj K
Florian Heigl (new acc)
Honored Contributor

Re: scsictl & scsi_max_qdepth

As a small update - back in december I found one of our old servers with local storage being hammered with disk IO. The problem had been slowly increasing when the amount of data thrown at the server increased by about 300%; some cron jobs of mine (reporting, rsyncing and such) came to the point where they spawned off before the last run was over.
I took a moment to look up vendor manuals for those 18k/10k disks in the server, and checked versus the scsictl reported queue depths.
They were all set at a depth of '8' whereas the vendors (prior to firmware replacement by HP, I'll admit) specified them at 64/128 tags depth. I changed it and took off 10% off the disk usage. Of course I also fixed the launch times for the cron jobs, but still I was midly surprised - WHY does HP not properly set those values on supported disks, and why did I never know how much of an impact it actually makes!

Keep tuning till it breaks,
Florian
yesterday I stood at the edge. Today I'm one step ahead.
ManojK_1
Valued Contributor

Re: scsictl & scsi_max_qdepth

Hi florian,

Still HP did not given any clear reply regarding this query as i have asked them directly with our customer id(HP is always saying our company is prestigious customer of them in our region).As per hp, increasing scsi_max_qdepth value may help.

In some extend what i have understood is that HP wants to hide something from the customer.

Manoj K
Thanks and Regards,
Manoj K
Hein van den Heuvel
Honored Contributor

Re: scsictl & scsi_max_qdepth

>> In some extend what i have understood is that HP wants to hide something from the customer.

I don't think so.

HPUX just opted for 'safe', working setting.

You have the option to improve on that.

This particular parameter is really VERY dependent on what is 'hiding' behind the LUN.
I write hiding, because there is no practical way to tell how deep you can go. There can be 1 disk behind a lun, or 100. There can be 64 MB cache shared with 8 luns, or 8 GB cache.

I think there is room in the scsi protocal to negotiate the maximum reasonable depth for a controller, but that controller may well be used fom multiple hosts. How would you propose that those hosts, which need not be able to communicate, negotiate which slice of the IO pie they are entitled to ?!

And... it's a good knob to know for Performance Consultants like myself :-).

Hein


ManojK_1
Valued Contributor

Re: scsictl & scsi_max_qdepth

Hi Hein,

Please don't be upset with the word "HP wants to hide something from the customer".

In Our environment more than 90% of the servers are from HP. Storage is HP EVA.

The application we are running on the servers are ORACLE and T24 Core banking systems and they are HP's partners.

Regarding the performance issue HP has collected all the details from the servers still they were not sure about the scsi_max_qdepth kerenel parameter.

Manoj K

Thanks and Regards,
Manoj K