vocal moth
I've just been asked what queue depth I recommend on a Linux OS for iSCSI workloads.
Any advice how to handle this question? Gather the necessary info etc.?
They tried with iodepth 64 and then doubled it seeing massive IOPS gains, but I never handled queue depth outside of FC and can't find any documentation about iSCSI specific settings.
quick moth
For optimal SCSI request queuing, the following changes can be made to the iscsid.conf:
vocal moth
Thanks! But it seems a bit old, is it still valid for later releases of ONTAP?
"ONTAP 9 to 9.10"
elfin fiber
yes, even though ASA can failover iSCSI LIFs I would always still use multi-pathing
so if you have an FAS/AFF you definitely need multi-pathing
tough gate
I think the multi-pathing part was not the question, but rather the queue depth part. In general you want as high a queue as possible, but at some point you're just wasting memory with no additional gain. Queueing is basically just there to hide the network latency from the client application
vocal moth
Are you saying "Test - increase - repeat" is the way?
I'm wondering if there could be consequences on the storage side.
tough gate
What consequences? If the storage can't keep up, it can't keep up, no matter the queue depth. NetApp recommends the values from the KB. Of course you can go higher or lower than that. But there is no single "correct" number for these settings. So without hard numbers that you are seeing (and the numbers you are expecting) this is all just crystal ball reading 🙂 Are you even having performance issues? If yes, what kind (throughput, latency, iops?)
atomic kraken
high queue depths that are actually used basically hide problems and will make some situations worse because one will have a higher number of in-flight operations that will get reset after time-outs and need to be re-transmitted. Queue depth just adds some flexibility for intermittent errors, burstiness, some natural in-flight timings (but most of those should be delt with in the tcp stack send/rcv buffers).