ADSM-L

Re: [ADSM-L] Excessive memory consumption by 5.5 Linux client on SLES 10.3 x86_64

2010-07-15 12:06:00
Subject: Re: [ADSM-L] Excessive memory consumption by 5.5 Linux client on SLES 10.3 x86_64
From: Robert Clark <robert.clark7 AT USBANK DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 15 Jul 2010 09:02:31 -0700
Dumb question, but have you examined the client to see if there are any
circular links?

(For example a link low in the tree that points higher in the tree.)

[RC]



From:
Wolfgang J Moeller <moeller AT GWDG DOT DE>
To:
ADSM-L AT VM.MARIST DOT EDU
Date:
07/15/2010 07:04 AM
Subject:
Re: [ADSM-L] Excessive memory consumption by 5.5 Linux client on SLES 10.3
x86_64
Sent by:
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>



Skylar Thompson wrote:

> I ran into something similar on RHEL4 when dealing with directories with
> lots of files (11 million in one of them - so many that ext3 b-tree
> indexing failed). I think even with MEMORYEFFICIENTBACKUP enabled, the
> client will still need to allocate enough memory to handle one directory
> at a time. Do you have any directories like that?

No, apart from a rather "standard" root file system - which accounts for
over 300k of the ~500k files involved, and typically makes for ~150 MB
"dsmc" memory consumption - the other (pretty large) files are evenly
spread over >20k directories.
And did you ever see _cumulative_ memory growth (aka "memory leak"?).

There got to be something pretty weird with this machine ...
I'm still working with TSM support.

> On 07/07/10 01:19, Wolfgang J Moeller wrote:
> > Good morning,
> >
> > on a (real big!) x86_64 machine, with freshly installed SuSE SLES
10.3,
> > scanning a mere ~500k files (and typically saving < 10,000 per run),
> > "dsmc" has been found to consume about 1.3 GByte of virtual memory
> > per single run. This is about tenfold from what you'd expect ...
> >
> > And even worse, in the case of running "dsmc sched", the memory
> > consumption is cumulative in the sense that after three runs,
> > virtual memory has grown to about the maximum of ~4 GB, so that
> > the next time the scheduler ought to run, it will simply refuse
> > to proceded with a "cannot obtain memory" message (that's how
> > the problem was discovered in the first place).
> >
> > Reproducible with "x86" Linux clients 5.5.2.7 and 5.5.1.4.
> > TSM server 5.5.2.1 on AIX, in case it matters.
> >
> > Sure running "dsmc" via the CAD is currently a work-around ... but how
long?
> >
> > Normal operation of the client system also involves a lot of 32-bit
code
> > (like the TSM client); I also performed a few simple 'malloc()' tests
-
> > no indication so far that the memory allocation was fundamentally
flawed.
> >
> > IBM support is rather stumped. Any ideas welcome!
> >
> > On this particular machine, I'd rather not experiment too much
> > with (potentially incompatible) client versions, unless it was known
> > that a recent 6.x version did indeed solve a problem of this kind ...

---

Best regards,

                 Wolfgang J. Moeller<moeller AT gwdg DOT de>

Tel. +49 551 201-1516 ... not representing ... GWDG, Goettingen, Germany



U.S. BANCORP made the following annotations
---------------------------------------------------------------------
Electronic Privacy Notice. This e-mail, and any attachments, contains 
information that is, or may be, covered by electronic communications privacy 
laws, and is also confidential and proprietary in nature. If you are not the 
intended recipient, please be advised that you are legally prohibited from 
retaining, using, copying, distributing, or otherwise disclosing this 
information in any manner. Instead, please reply to the sender that you have 
received this communication in error, and then immediately delete it. Thank you 
in advance for your cooperation.



---------------------------------------------------------------------