IBM AIX Max que depth

[Brian Hope]

Need some help. I have an IBM P570 with an HBA 5716 on an EVA 5000. Looking to see what Que depth is best practice for this configuration. It is currently set at 1. Thanks,

[Amar_Joshi · Accepted solution]

Hey Brian,

First I am confused how did you see the queue-depth? unlike Windows, AIX doesn't maintain queue_depth on HBA (as far as I know) it's maintained on hdisks.
to check: run "lsattr -El hdisk#" and see what's the queue_depth.

Now, concern with the parameter, 1 obviously very small, average systems I have seen with a queue_depth of 8 (some windows system maintain 32 also on EVA and they are fine). I personally suggest to change it to 8 and see. If you gain performance probably you may try with 16 or 32 and then see which one suits to your environment.
to change: run "chdev hdisk# -a queue_depth=8" command.

Hope this helps...

[chris callihan]

what multipath software are you using - that will also matter

[Brian Hope]

You are abosolutly (think I spelt that right) correct on the que depth being on the LUN or Hdisk itself. I had gotten the information from our AIX team and something got loss in translation. We have never had to mess with these settings before. This is the answer I was looking for. Thanks. Points are comming. :-)

[Bret Graham]

You are seeing a common problem with the EVA3/5000s and AIX. Due to a difference in expectations, AIX will set the queue depth to one and this cannot be changed. You may be able to use the chdev command to change the value but internally, it will always be one.

This problem is present in the EVA3/5000s only. With the EVA4/6/8000s and XCS 6.000 the problem was resolved where you can use any supported queue depth in AIX.

Have you installed the HP MPIO kits to properly define these hdisks to AIX? That is highly recommended but it also will not allow the queue depth to be anything but one.

Regards,
Bret

[Brian Hope]

How can you verify if AIX internally is seeing the que depth as 1 instead of 8,16,...?
Yes we have installed the the HP MPIO ODM with the AIX native MPIO for EVA.
Does it make a difference if you are running the VCS 4000 series code over the 3000 series code for AIX running on EVA5000 as far as the que depth being seen correctly as 8,16,... que depth?

[Bret Graham]

Brian,

I apologize that I don't have an answer on how to verify the queue depth is one. I would imagine it would involve kdb or similar.

The issue has to do with a certain feature that AIX expects to see from any fibre/scsi device it configures. The EVA does not provide this feature so AIX sets the queue depth to one.

The ability to change the queue depth to a value higher than one can only be done with AIX and an EVA4/6/8000 running XCS of 6.000 or higher.

Bret

[Tom O'Toole]

Hi Bret,

I'm using xcs 6.100, devices.fcp.disk.HP.hsv.mpio.rte 1.0.1.0 and I'm still not convinced a >1 queue_depth has been 'actualized'.

I'm using iostat -m -D to monitor disk stats and I'm seeing a ton of sqfull (service queue full) events occurring. I think we are getting one for each I/O queued. I have tried to increase the queue_depth attribute on the hdisk in question, from the default of 8, to 16, and then 64, with no obvious difference.

I don't think AIX with EVA MPIO is actually using the large queue_depth because there is no large queue on the EVA (using evaperf hps), and the iostat is reporting average service and wait queue sizes of less than one. Since we're getting spfull, this makes me think the actual queue_depth being used is 1. In addition, the average wait queue time can get large compared to the average read service time, so I feel it would improve performance if more I/O could be queued.

Do you successfully get decent size queues on the EVA host ports (or is evaperf reporting something different thasn what I expect it to?). Thanks!

[Kevin Cleveland]

Bret,

What feature is it that the array does not implement that AIX looks for? I have a fibre channel attached device that exhibits this issue and would like to know what needs to be implemented to support higher queue depths.

Thanks for your time.