Thanks for reporting back. This is something we've struggled with too.
I'll have to give nscd a shot.

On 02/ 1/11 01:16 AM, Wolfgang J Moeller wrote:

Last year, I had reported ...

>  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 [...]
>
>  Sure running "dsmc" via the CAD is currently a work-around ... but how long?
>[...]
>  IBM support is rather stumped. Any ideas welcome!

After lots&  lots of digging, IBM support finally came up
with the idea of testing memory usage of the UNIX function "getpwuid()" -
used by "dsmc" in order to find the files' owner name -
and it turned out that when LDAP client authorization was involved,
this function would leak ~300kB of memory_per_call_!

It also turned out that "nscd" (name service caching daemon) was not
running - once started, the memory leak would be experienced by "nscd",
and no longer by "dsmc". However, in order to keep "nscd" running,
it would require regular re-starts because of its enormous memory growth
(as it happens, this machine also has lots of unrelated LDAP client load).

It is rumored that various LDAP clients based on the same "open source"
exhibit this behaviour, and apparently the bug isn't fixed yet. Watch out!

Best regards,

        Wolfgang J. Moeller<moeller AT gwdg DOT de>

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

--
-- Skylar Thompson (skylar2 AT u.washington DOT edu)
-- Genome Sciences Department, System Administrator
-- Foege Building S048, (206)-685-7354
-- University of Washington School of Medicine