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
Channel Access Server V4.8
Client Name="archiver", Client Host="krynfsb", V4.11, Channel Count=961
TId=0XA56A34, Protocol=TCP, Socket FD=4
Secs since last send 27.35, Secs since last receive 27.35
Unprocessed request bytes=0, Undelivered response bytes=0
Client's DNS Host Name krynfsb:51657 State=up
3487084 bytes allocated
ttfKryoFV:burtEnable_bi(54rw) CMTBSTC2R8_temp(54rw) CMTBSTC2R8_temp(54rw)
CMTBSTC2R8_temp(54rw) CMTBSTC2R8_temp(54rw) CMTBSTC2R8_temp(54rw)
CMTBSTC2R8_temp(54rw) CMTBSTC2R8_temp(54rw) CMTBSTC2R8_temp(54rw)
CMTBSTC2V5_temp(54rw) CMTBSTC2V5_temp(54rw) CMTBSTC2V5_temp(54rw)
<... many channels and clients more ...>
Client Name="", Client Host="", V4.0, Channel Count=0
TId=0XC5BD5C, Protocol=UDP, Socket FD=26
Secs since last send 8194.07, Secs since last receive 6.57
Unprocessed request bytes=0, Undelivered response bytes=0
Client's DNS Host Name 131.169.112.236:37952 State=up
32926 bytes allocated
There are currently 1091524 bytes on the server's free list
22 client(s), 2677 channel(s), and 2236 event(s) (monitors)
The server's resource id conversion table:
Bucket entries in use = 2443 bytes in use = 55492
Bucket entries/hash id - mean = 0.596436 std dev = 0.688548 max = 3
Channel Access Address List
131.169.113.255:5065
- Replies:
- RE: Memory Problem related to CA? Jeff Hill
- RE: Memory Problem related to CA? Jeff Hill
- RE: Memory Problem related to CA? Jeff Hill
- References:
- Memory Problem related to CA? Schoeneburg, Bernd
- RE: Memory Problem related to CA? Jeff Hill
- Navigate by Date:
- Prev:
RE: Inexpensive PLC Ethernet w/EPICS Driver Mark Rivers
- Next:
Re: Listen to multiple events Korhonen Timo
- 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
|