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<moel...@gwdg.de> Tel. +49 551 201-1516 ... not representing ... GWDG, Goettingen, Germany