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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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/[email protected]/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 < > [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 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 at www.arslist.org > attend wwrug10 www.wwrug.com ARSlist: "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 at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
