We have apps where users query the system with webservices couple thousand times a day. It is through webservice calls. Any timedout webservice calls or webservice calls returning large data set etc...are causing memory leaks when executed over and over like several thousand times.
On Apr 7, 3:28 pm, Robert Halstead <badbee...@gmail.com> wrote: > Do you see the memory leak on just deneral usage of the midtier? Or is > there a specific action to replicate? Is this through the mid-tier > interface, or webservice call? > > > > > > On Wed, Apr 7, 2010 at 3:22 PM, patchsk <vamsi...@gmail.com> wrote: > > It is under limited availability and is going through UAT as per our > > support rep. > > We are expecting around end of this month, but she can not speak for > > sure as it depends on their test results. > > > On Apr 7, 1:52 pm, Robert Halstead <badbee...@gmail.com> wrote: > > > patchsk, > > > > We do utiize the midtier a lot with our custom applications and tools as > > > that is the only cross-platform way to communicate with remedy without > > using > > > their java api. That would explain a lot actually. I'll have do some > > > testing with our other apps to see if I can replicate in patch 004. I > > know > > > BMC isn't very forthcoming with their patch schedule, but did they say > > when > > > patch 005 was going to go live? > > > > Thanks for the heads up though :) > > > > On Wed, Apr 7, 2010 at 2:47 PM, patchsk <vamsi...@gmail.com> wrote: > > > > We have seen memory issues too on Solaris5.10, ARSystem 7.5patch3. > > > > BMC has found three memory leaks related to be caused by webservice > > > > calls i.e., ARXMLGE api calls after a long investigation. Regular user > > > > tool we did not see much issues. > > > > They supposed to fix it with patch005. > > > > Also libumem worked better for us compared to default memory handler, > > > > even though they say libumem is only effective for older solaris os. > > > > After creating a ticket basically BMC has given us a script to log > > > > server env (prstat,vmstat etc..) at regualar intervals. > > > > We provided them those logs with remedy api logs and they did the > > > > investigation based on that. > > > > We had to fight a lot though to escalate it to server team. > > > > > On Apr 7, 10:27 am, Robert Halstead <badbee...@gmail.com> wrote: > > > > > Axton, > > > > > > Once I have this all setup with libumem and enable the UMEM_DEBUG and > > > > > UMEM_LOGGING environment variables, do I just wait for the leak to > > occur > > > > to > > > > > the point where the app crashes? Does the system produce a core file > > at > > > > > that point? Do I then perform the MDB commands on that core file? > > > > > > Reading the article on dbx (RTC), it looks like I can connect to the > > > > running > > > > > program without stopping it but I need to have the Sun Studio > > installed > > > > to > > > > > get the dbx program correct? > > > > > > On Tue, Apr 6, 2010 at 8:14 PM, Axton <axton.gr...@gmail.com> wrote: > > > > > > ** Since you are on Solaris/sparc you have some really good options > > for > > > > > > seeing if there are memory leaks. Look into the slab memory > > allocator > > > > > > (libumem). > > > > > > >http://blogs.sun.com/ahl/entry/solaris_10_top_11_20 > > > > > > > <http://blogs.sun.com/ahl/entry/solaris_10_top_11_20>There are > > > > actually > > > > > > performance benefits to using this memory allocator to the standard > > > > libc > > > > > > (though it does make the memory footprint slightly larger), but > > it's > > > > going > > > > > > to hard stop your software (sigsegv, sigbus, etc.) in the event > > nasty > > > > things > > > > > > are going on that shouldn't be going on. Good news is that it > > tells > > > > you > > > > > > what/where if you tell your system to generate a core in the event. > > > > > > > Once you have things running under libumem, you can put some checks > > on > > > > > > memory usage (see the following): > > > > > > UMEM_DEBUG > > > > > > UMEM_LOGGING > > > > > > > Once you do that, it makes some handy options available in dbx > > (RTC): > > > > > > http://www.mail-archive.com/arsl...@arslist.org/msg33614.html > > > > > >http://www.fortran-2000.com/ArnaudRecipes/SunMemoryDB.html#SunDbx > > > > > > > You can attach the debugger to the process in flight to check for > > > > memory > > > > > > leaks: > > >http://technopark02.blogspot.com/2005/10/sun-studio-investigating-mem. > > > > .. > > > > > > > See here for the high-level gory details. Pretty cool stuff: > > > > > >http://developers.sun.com/solaris/articles/libumem_library.html > > > > > > > Axton Grams > > > > > > > On Tue, Apr 6, 2010 at 4:38 PM, Robert Halstead < > > badbee...@gmail.com > > > > >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 WWRUG10www.wwrug.comARSlist:"Where the Answers Are"_ > > > > > > > _attend WWRUG10www.wwrug.comARSlist:"Where the Answers Are"_ > > > > > > -- > > > > > "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 > > > ___________________________________________________________________________ > > > > ____ > > > > > UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org > > > > > attend wwrug10www.wwrug.comARSlist:"Where the Answers Are" > > > ___________________________________________________________________________ > > ____ > > > > UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org > > > > attend wwrug10www.wwrug.comARSlist:"Where the Answers Are" > > > > -- > > > "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 > > > ___________________________________________________________________________ > > ____ > > > UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org > > > attend wwrug10www.wwrug.comARSlist:"Where the Answers Are" > > > ___________________________________________________________________________ > > ____ > > UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org > > attend wwrug10www.wwrug.comARSlist: "Where the Answers Are" > > -- > "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 > > ___________________________________________________________________________ > ____ > UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org > attend wwrug10www.wwrug.comARSlist: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
