EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  <20082009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  <20082009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: Memory Problem related to CA?
From: "Jeff Hill" <[email protected]>
To: "'Schoeneburg, Bernd'" <[email protected]>
Cc: [email protected]
Date: Tue, 18 Mar 2008 08:26:11 -0600
> 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.

This means that your client has subscribed (called ca_create_subscription or
ca_add_event) 54 times! One option of course will be to find the misbehaved
client (the IP address is in the casr report) and convince its author to
recode his application.

> 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.

We don't currently have an option to do this, but considering that vxWorks
memory allocation is much better than in the past perhaps one option that
should be considered for R3.15 is to use free lists dedicated to each client
that are returned to system pool when the client disconnects.

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
> >


Replies:
Re: Memory Problem related to CA? Andrew Johnson
References:
Memory Problem related to CA? Schoeneburg, Bernd
RE: Memory Problem related to CA? Jeff Hill
Re: Memory Problem related to CA? Schoeneburg, Bernd

Navigate by Date:
Prev: Re: Listen to multiple events Korhonen Timo
Next: RE: Memory Problem related to CA? Jeff Hill
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  <20082009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Memory Problem related to CA? Schoeneburg, Bernd
Next: Re: Memory Problem related to CA? Andrew Johnson
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  <20082009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·