Discussion on queue depth

Hello friends. It has been quite a while and lots of things have changed since my last post. I am hoping to break out at least 1 post per month for the remainder of this year to deliver some helpful information in designing and tuning your Spectrum Virtualize storage systems. For the first post of the year I want to talk about queue depth settings.

Historically IBM has put out a formula for calculating queue depth here. However, this calculation is not ideal for the newest systems on the newer code versions. In the current releases the queue depth on the system is a fixed number per physical port on each node. As a result, in order to avoid queue full on the system you should be careful not to set the aggregate queue depth of all hosts accessing a single physical port on the system greater than 2048.

Once the target (in our case Spectrum Virtualize) hits queue full, the system won't be able to accept any additional io requests on that port. This can result in dropped commands which would require hosts to abort and retry io which can have serious application impact depending on how various server and application timeout settings align on the servers.

IBM will be updating the Knowledge Center entry around this subject in the next release.

I hope you all found this helpful and informative. If you have any questions or concerns please leave a comment, ask me on Twitter @fincherjc, or reach out to me on Linkedin.

Comments

  1. Hello Jordan, important topic.
    Is there a metric, either in SV /dumps/iostats or in Spectrum Control that reflects the utilization of a physical port's queue?
    Cheers, Joachim

    ReplyDelete
    Replies
    1. Hello Joachim. The information in /dumps/iostats are pre-defined metrics that are averaged over minutes (defined by the stats interval shown in lssystem). Because of this there is not a practical way to monitor the queue utilization. Commands only sit in this queue until io is cached (typically microseconds to miliseconds time range) so iostat would not be a practical place to monitor.

      Delete

Post a Comment

Popular posts from this blog

Why you should always use DRAID

Remote Copy Data Patterns and Partnership Tuning

What is a 1920 and why is it happening?