PS: Subscriptions are somewhat memory intensive so that several subscription
update events can be buffered on the event queue when the scan tasks,
server, or network are busy.
Jeff
> -----Original Message-----
> From: Jeff Hill [mailto:[email protected]]
> Sent: Tuesday, March 18, 2008 8:26 AM
> To: 'Schoeneburg, Bernd'
> Cc: '[email protected]'
> Subject: RE: Memory Problem related to CA?
>
> > 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
> > >
- 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: Memory Problem related to CA? Jeff Hill
- Next:
RE: Memory Problem related to CA? Jeff Hill
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
<2008>
2009
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? Jeff Hill
- Next:
RE: Memory Problem related to CA? Jeff Hill
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
<2008>
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|