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