Are you making form or workflow changes on that server while users are using 
it?  Are you creating new ITSM Support Groups while other are logged on to the 
system?  Is Development Cache Mode turned off?  If the answer to the last 
question is “yes”, then either of the first two actions will cause the server 
to create a new copy of the workflow/forms cache in memory until the users that 
were logged in during the change log out for a short period.  For example, if 
you create a support group, the server thinks it needs to recache everything, 
so it creates a copy of the current cache for those that are currently logged 
in and then pulls the new one from the server to reflect the changes (or 
something along those lines).  In any case, the result is that you then have 
multiple copies of the cache in memory, which can easily consume all of your 
memory depending on how much workflow you have loaded and how many times it 
pulls a new copy of the cache into memory.

That said, my experience is based on ARS 7.1, but I wouldn’t be surprised if 
it’s essentially the same in 7.5…

Lyle

From: Action Request System discussion list(ARSList) 
[mailto:[email protected]] On Behalf Of Robert Halstead
Sent: Tuesday, April 06, 2010 3:39 PM
To: [email protected]
Subject: Finding memory leaks in the AR System

** Hey all,

We're running AR System 7.5 patch 004 and we are finding that our server is 
eating up memory and not releasing it.  We are in the UAT process and have 
roughly 10 testers testing the system.  During this time we've noticed a huge 
memory allocation and eventually the arserverd process would consume 2-3 gigs 
of memory and all the swap space, at which point the machine comes to it's 
knees and the process needs to be forcibly killed or the box hard restarted.

I remember reading somewhere that the AR System doesn't release memory for 
large queries, but instead just reuses the memory address space.  Is this still 
true for 7.5?  Are there any type of performance configurations I can add to 
the ar.conf file to allow the AR System to release the memory it allocates?  Or 
to prevent a query from taking all the available memory on the box?

I thought the AR System used temporary file storage for storaging a large SQL 
result?  Our 6.3 AR System stores temporary query result files in 
/var/tmp/ARpen* files, does 7.5 not do the same thing?

I just thought I would ping the list before I open a ticket with BMC and see if 
anyone else is seeing a memory leak or has had this problem occur to them in 
the past.  Though I'm not sure who all is running the latest 7.5 AR System.

Any help would be appreciated as I'm not sure what BMC will want me to look for 
to determine a memory leak and I don't like to engage them without some sort of 
proof that one exists.

Our server specs are the following:

System Configuration: Sun Microsystems  sun4u Sun Fire V210
System clock frequency: 167 MHZ
Memory size: 4GB

==================================== CPUs ====================================
               E$          CPU                    CPU
CPU  Freq      Size        Implementation         Mask    Status      Location
---  --------  ----------  ---------------------  -----   ------      --------
0    1002 MHz  1MB         SUNW,UltraSPARC-IIIi    2.4    on-line     MB/P0
1    1002 MHz  1MB         SUNW,UltraSPARC-IIIi    2.4    on-line     MB/P1

AR System 7.5 patch 004
Apache Tomcat 5.5.28 / Midtier 7.5 patch 004

If you guys need more server specs let me know.  We are trying to replicate the 
issue but we are unsure how it happens and don't really know where to start.

Thanks for the help.

--
"A fool acts, regardless; knowing well that he is wrong. The ignoramus acts on 
only what he knows, but all that he knows.
The ignoramus may be saved, but the fool knows that he is doomed."

Bob Halstead
_attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_


 NOTICE: This email message is for the sole use of the intended recipient(s) 
and may contain confidential and privileged information. Any unauthorized 
review, use, disclosure or distribution is prohibited. If you are not the 
intended recipient, please contact the sender by reply email and destroy all 
copies of the original message.


Reply via email to