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: "Schoeneburg, Bernd" <[email protected]>
To: Jeff Hill <[email protected]>
Cc: [email protected]
Date: Tue, 18 Mar 2008 11:48:02 +0100
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  <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? 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  <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 ·