Conference pamsrc::decmessageq

2895.0. "MSGTQL guidelines?" by WHOS01::ELKIND (Steve Elkind, Digital SI @WHO) Tue Jun 03 1997 16:41

    The DmQ for Unix installation guidelines in the v3.2A release notes
    suggest that MSGTQL should be at least equal to MSGMNI.
    
    In our scenario, there is a "client" group in which front-end GUI
    client apps attach to temporary queues, and then start request-response
    transactions with servers on remote groups.  As such, I expect:
    	- not all queues will be attached to at any one time, but most will
    	  be (perhaps 750 out of 800)
    	- not all queues attached to will be in active use at any one time,
    	  e.g., client GUI app is waiting for user input
    	- most clients should not have more than 2-3 pending messages when
    	  they are actively using the queues.
    
    At first, I thought that MSGTQL=MSGMNI would be adequate, based on the
    above, but now I'm starting to wonder.  Does anyone have any general
    guidelines or rules of thumb for sizing MSGTQL?  Naturally, we are in
    early innings so we have no hard statistics or accurate predictions on
    the messaging rates and queue depths for the dozen or so GUI apps.
    
    Also, would running out of message headers be one cause of the -130
    (REMQUEUEFAIL) error?  I got a call from the support folk for one of
    the backend servers that their server app had seen this and wanted to
    know what could cause it, all I could say was IPC resource exhaustion
    (which the CSC told me).  Would this cause a log entry in the group log
    file?
    
    Thanks

    
    Each time a process make a request of the queuing engine
    its consumes one message header (MSGTQL).  When  the  QE
    dequeues the request the message header is  returned  to
    the system.  When the QE responds to the process  making
    the request,  it again consumes one message header. When
    the process dequeues the response the message  header is
    returned to the system.
    
    If every process submits a request at the same time then
    you need one message header per process hence the MSGTQL
    should be at least equal to MSGMNI.  In reality you  can
    consume more MSGTQL if your program is making pams calls
    in an interrupt.  This would allow a single  process  to
    have multiple requests  outstanding  at  the  same  time
    and thus consume more than one message header.  In  prac-
    tice,  though not everyone is making a  request  at  the
    same time and MSGTQL can be much lower than MSGMNI.
    
    If a process makes a request of the queuing  engine  and
    there are no message headers available, then the process
    blocks until one becomes available.   No error is return-
    ed or reported because none exists.  Having your  MSGTQL
    parameter set too low generally results in  poor  perfor-
    mance because multiple processes are competing for a lim-
    ited resource,  but that is all.
    
    _sjz.