🚀 go-pugleaf

In article <10115@ncratl.AtlantaGA.NCR.COM>, hroth@ncratl.AtlantaGA.NCR.COM (Harris Roth) writes:
|> I have used IPC message queues to communicate between applications.  While 
|> running the system through stress testing, occaisionally, the communication 
|> between processes comes to a halt.  After running ipcs -a, I see that one of 
|> the processes is stuck on a msgsnd request.  It appears that 
|> wchan points to the send function.  Has anybody else had IPC message queue
|> sending and receiving go belly up?  I am using the option which requests that 
|> the calling process sleep until the message can be sent to the queue 
|> (IPC_WAIT).  By the way, I am using SVR4.
|> 
|> Any insight via post or E-mail is appreciated in advance.
|> 
|> Regards,
|> 
|> Harris J. Roth 
|> -- 
|> Harris J. Roth, Senior Programmer Analyst |
|> System Software                           |   hroth@ncratl.atlantaga.NCR.COM 
|> Transaction Terminal Systems Division     |
|> NCR E&M Atlanta                           |   (404) 623-7749

There are several important kernel defined limits that can cause this. 
Exactly what you will have depends on your port. Typical are:

   A limit on the total number of messages that may be in a queue.
   A limit on the total length of all messages in a queue.
   A limit on the total length of all messages in all queues.

The per-queue limits cause problems if say, many clients talk to one
server over a queue. So many clients send messages to the server that
the queue fills, and clients have to sleep, waiting for space on the
queue. Meanwhile, the server has completed its task, and wants to send
a reply to the client it has been working for. Trouble is, it cannot
send the message because the queue is full, and so it sleeps. Only the
server can read client requests off the queue, so freeing it, but it
is asleep. 

A solution to this problem is to use a 'downstream' queue for requests,
and an 'upstream' queue for replies. For enhanced buffering, I have used
many downstream queues and one upstream queue with success.

Another problem can occur if the total amount of memory available is less
than the total number of queues multiplied by the total amount of
memory available per queue. In this case the global limits can mean that
a msgsnd() blocks trying to put to an otherwise unfilled queue.

Solution 1 is to make the global limit big enough. Sometimes people 
deliberately create 'impossible' kernels so that transient loads can 
allow some queues to hog memory, and improve throughput. When this is
done, deadlock avoidance must be considered in the design of the
application.

   Hope this helps, Alan

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To arrive at the simplest truth, as Newton knew and practised, requires years
of contemplation. Not activity. Not reasoning. Not calculating. Not busy 
behaviour of any kind. Not reading. Not talking. Not making an effort. Simply 
bearing in mind what it is one needs to know.

   George Spencer-Brown, Laws of Form
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~