Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Thu, 12 May 2005 17:38:10 -0600

> Maybe it would suffice to deallocate free-list memory as soon
> as a large enough portion of it is unused?

This is not the current design, but this could be considered. The
problem will be of course deciding how long to wait and how much
to return to pool. Otherwise, as soon as you return it to pool a
client might come along and ask for it again, and you have not
gained as much by going to a free list. One possibility would be
to maintain an independent free list for each client that
connects thereby return all of what the client requested to pool
when he disconnects. That wouldn't work very well when there are
poorly behaved clients that continuously connect and disconnect.

Jeff

> -----Original Message-----
> From: Benjamin Franksen [mailto:[email protected]]
> Sent: Thursday, May 12, 2005 2:51 PM
> To: [email protected]
> Subject: Re: excessive ioc memory utilization
> 
> On Wednesday 11 May 2005 01:13, Jeff Hill wrote:
> > > The culprit was a misbehaving channel access client.
> Somehow
> > > it connected tens of thousands of channels which increased
> the
> > > memory usage by CA.  When it was stopped the memory on the
> > > IOC was not returned.
> >
> > [...]
> > > Is this the expected behavior of CA?
> >
> > Yes CA uses free lists by design, and CA does not implement
> > quotas to stop a badly behaved client application from
> > introducing unacceptable load should it create too many
> channels,
> > subscriptions, etc.
> 
> Maybe it would suffice to deallocate free-list memory as soon
> as a large
> enough portion of it is unused?
> 
> Ben

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System