Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Tue, 18 Mar 2008 08:48:17 -0600

PPS: So of course subscribing 54 times isn't unusual, but for one particular
client to subscribe 54 times on each of its channel then we have 54 times N
channels of subscriptions which can be a suboptimal use of the IOCs memory.

Jeff

> -----Original Message-----
> From: Schoeneburg, Bernd [mailto:[email protected]]
> Sent: Tuesday, March 18, 2008 4:48 AM
> To: Jeff Hill
> Cc: [email protected]
> Subject: Re: Memory Problem related to CA?
> 
> Hello Jeff,
> thank you for your hints. Finally I had to reboot this ioc, because the
> available memory was very rare.
> I have checked the CA connections before. There was one connection which
> occupied 3.5 MB of memory for 961 channels. After reboot this client
> connection used only 200 kB. I looked at the casr-output. There are
> additional informations for each channel. What does the first number in
> parenthesis mean? Something like an element count. For this sick
connection
> it was 54! Please look at the attachment.
> Is there a possibility to purge the ioc from such connections? The best
> would be to disconnect all CA connections and give back (at least a part
> of) the additionally allocated memory back to the system pool. This would
be
> a great tool.
> 
> Bernd
> 
> 
> Jeff Hill schrieb:
> > Hello Bernd,
> >
> > Yes, to avoid problems with fragmentation, the CA server does have
> > several free memory pools. As you suspect, the free lists that it uses
> > are not returned to the system pool, and so its memory usage high
> > water mark will persist even if the client load decreases. One can
> > examine how much memory it has in its pocket using the "casr" command
> > specifying higher interest levels.
> >
> > With R3.13 there are more raw malloc/calloc requests in the ca server
> > (that don't use a free list) and so there is greater potential for
> > fragmenting the system memory pool. More recent versions of vxWorks
> > use a best fit memory allocation scheme so fragmentation of the system
> > memory pool is less common, but of course memory allocation overhead
> > is also higher. You can examine some statistics of the system memory
pool
> with the "memShow" command.
> >
> >> Can the channel access pool become fragmented?
> >
> > Probably not because it uses free lists - each of them dedicated to a
> > particular size of block that is needed.
> >
> > Jeff
> >
> >> -----Original Message-----
> >> From: [email protected]
> >> [mailto:[email protected]]
> >> On Behalf Of Schoeneburg, Bernd
> >> Sent: Friday, March 14, 2008 10:20 AM
> >> To: [email protected]
> >> Subject: Memory Problem related to CA?
> >>
> >> Hi all,
> >> on some IOCs we see that the free memory becomes less and less.
> >> Especially when we restart our channel archiver, the free memory in
> >> the IOCs becomes much less.
> >> My possible explanation for this is that channel access has not a
> >> free memory block of the desired (big) size in its private pool, so
> >> that additional memory from the system pool is allocated - and never
> free'd.
> >> Is this possible? Can the channel access pool become fragmented? If
YES:
> >> Is there a solution for this in later versions? Or a patch?
> >>
> >> We are using Epics 3.13.10 with vxWorks 5.3.1 on mvme162-532A (16 MB)
> >>
> >> Thank you
> >>
> >> Bernd
> >

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System