Open a ticket with BMC. Just make sure you have ALL the files they will want or you will wind up playing volleyball email. At a minimum: Do a trace on memory usage; You better make the case here. How long, how fast, etc. Monitor threads. Use prstat, truss, whatever debug tools at your disposal. Check the pfiles, give them filehandle usage. Capture the memory footprint right before it dies. Have your ar.conf file ready..
On Tue, Apr 6, 2010 at 4:38 PM, Robert Halstead <[email protected]> wrote: > ** 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"_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
