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
> >
- 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? Andrew Johnson
- 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:
EDM fundamentals .... Emmanuel Mayssat
- 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
|