I was asked this at a customer, and we found this is not covered in the Knowledge Centre or anywhere else. I gave the classic performance response 'it depends'. The customer then said 'ok it depends on what?', and I said I would look into it and write it up. I'd like to thank Gwydion Tudur for help with the anwer.
There are two parts to the answer - an easy part, and a hard part. I'll give an overview of how SMDS works, and cover the easy part first.
If there is a shortage of buffers this means some requests are slower, and can lead to increased IO to the data sets.
Each queue manager has an SMDS which it writes to. An entry is still written to the Coupling Facility structure for each message offloaded to SMDS, and contains data such as QueueManagerName.Record number_in_data_ set.
If my application is on MQP1, and it does an MQPUT the information may be like MQP1.9009.
When an MQGET is issued the data in the CF structure says where to get the message from. For example, if my application is connected to MQP1, and the CF Structure data says MQPQ,4993 then the data set for queue manager MQPQ is used and record 4993 is read.
If the message was put using the same queue manager as the application doing the MQGET then the data may already be in the SMDS buffers, and so you avoid a disk read.
Once a message has been deleted the buffer is marked as empty.
The easy part
The queue manager needs to write the message data to SMDS. To do this it will use a buffer.
- If there is no buffer available then the application will wait for a free buffer.
- If the data fits into one buffer, then one buffer is used.
- If the data is bigger than one buffer, and if buffers are available, then more buffers will be used, and the IOs done in parallel.
- If there is a shortage of buffers then the application reuses the same buffer, and the IOs are done sequentially.
As soon as an IO has completed, the buffer is available for reuse.
If the put message rate is low, and the message data fits into one buffer, then one buffer may be enough. As the put rate increases then there will be more IOs in parallel and so more buffers may be needed.
If there are bigger messages then more buffers should be used The same logic applies when getting messages from an SMDS, but see below for the hard bit.
You need enough buffers to be able to do all of your IOs without waiting for buffers. If you use the DISPLY USAGE TYPE(SMDS) command it tells you about the buffers in use. If the value of Lowest free is negative then you have had applications waiting - and you should increase the number of buffers by at least this value. For many people the defaults are fine.
The hard part
The simple view above is fine for many MQ environments. Having more buffers may improve performance when getting messages from the SMDS on the same queue manager.
After data is written to the SMDS the data is kept in a buffer until the buffer needs to be reused. If an MQGET is issued, and the data is still in a buffer, then the buffer is reused, and this avoids an IO to read from the SMDS. This is faster than having to read from the SMDS. In the DISPLAY USAGE TYPE(SMDS) command, the 'saved' buffers have valid data. The reads saved % tells you what proportion of the MQGET requests were satisfied from the Saved buffers.
This use of a saved buffer to read a message will only apply to messages put by the queue manager where the MQGET is issued - if you get a message from a different queue manager, it is in the other queue manager's buffer, not where the MQGET is issued from.
If an application browses a message from any queue manager's SMDS, and then re-browses, or gets the message, the data may be in saved buffers.
If the queue depths are low (for example below 100) then having 100 buffers may be enough so the MQGETs are from the buffer and not from the disk.
If the queue depth is high, or you are using very large messages then you may need many buffers. As long as Saved buffers is less than Total buffers your gets should be from the SMDS buffers.
It may be impractical to have enough buffers to avoid all reads from the data set. If you have a very large number of buffers, then this will use a lot of virtual storage, which will need a lot of real storage, and both of these may impact the z/OS system - more auxiliary storage required, and more real storage to avoid paging.
If you have an application where the message is put and then immediately got, this may use a saved buffer. If you have an application where the messages are long lived, then the data may not be in saved buffers.
The hard part of sizing the number of SMDS buffers is to allocate enough for most of the time -but not too many so they cause problems.
The best way to find out is to gradually increase the number of buffers and see if you get benefit without causing problems. You may find that a number like 100 buffers is enough.
What you need to do now
Use the DISPLY USAGE TYPE(SMDS) command and check the lowest free is positive. If not then increase the number of buffers.