NDMPD memory leak?

Steve[color=blue]
> These appear to work, but now NDMPD.NLM is eating all the memory - in a recent
> test this morning NDMPD's share of the memory jumped from 239k to 100mb,
> and then slowly reduced back to previous levels again.[/color]

Does this actually cause a problem with other applications/user
logins/etc.? What I find is that when BE runs a backup, if there's
available memory/processing power there to use, BE will use it, but
relinquish it when other apps require it.

As long as BE *does* release it (which it appears to do in your case)
and doesn't affect other apps, then it seems to be working correctly.

Michael
--
"If it jams, force it. If it breaks, you probably
needed a new one anyway"

* Please post replies via the newsgroup *

Hi,

Have recently applied fixes intended to stop TSAFS and NSS nlm's eating all
the memory when backing up on NW65SP2 servers using BackupExec 9.10 1127.


These appear to work, but now NDMPD.NLM is eating all the memory - in a recent
test this morning NDMPD's share of the memory jumped from 239k to 100mb,
and then slowly reduced back to previous levels again.

Anyone know why this is happening and what I can do about it?

Thanks,

Steve Law

We've seen this several times in our organization. It started when we went
from BE 9.0 to BE 9.1. I have gotten it to work on one version of 9.1, but
can't remember which. When we backup a volume that might take 12-24 hrs,
200 GB volume, the server will run out of memory and crash. Differentials
will work all week long, but full backups would crash every time. Veritas
support was of no help.

Michael <boing@myrealbox.com> wrote:[color=blue]
>Steve[color=green]
>> These appear to work, but now NDMPD.NLM is eating all the memory - in[/color][/color]
a recent[color=blue][color=green]
>> test this morning NDMPD's share of the memory jumped from 239k to 100mb,
>> and then slowly reduced back to previous levels again.[/color]
>
>Does this actually cause a problem with other applications/user
>logins/etc.? What I find is that when BE runs a backup, if there's
>available memory/processing power there to use, BE will use it, but
>relinquish it when other apps require it.
>
>As long as BE *does* release it (which it appears to do in your case)
>and doesn't affect other apps, then it seems to be working correctly.
>
>Michael
>--
>"If it jams, force it. If it breaks, you probably
>needed a new one anyway"
>
>* Please post replies via the newsgroup *[/color]

Hi Bill,

Had fogotten about my original post here, just by chance I looked today.
This is still a problem for us too. We're using Netware 6.5 SP2 with all
patches including post SP2 nss patches, and Backupexec 9.1 build 1151.

I've been in touch with a Novell memory expert who has guided me through
tweaking memory usage so the config is exactly what it should be. But if
I stop the TSA's from using excessive memory (either TSAFS or TSA600, it
doesn't matter which I use) then NDMPD.NLM starts eating all the spare memory
until the server crashes. As it's a third-party nlm the only thing the Novell
engineer could do was tell me to talk to Veritas.

Other servers lose memory too, but not to the same debree as this one. The
only thing different about it is that the main data volume is approx 150bg
of small gif files - averaging about 40k. There should be some way to back
this up, even if it's a very slow way. At the moment we cannot get a full
backup.


Steve Law





"Bill Anderson" <banderson20@gmail.com> wrote:[color=blue]
>
>We've seen this several times in our organization. It started when we went
>from BE 9.0 to BE 9.1. I have gotten it to work on one version of 9.1,[/color]
but[color=blue]
>can't remember which. When we backup a volume that might take 12-24 hrs,
>200 GB volume, the server will run out of memory and crash. Differentials
>will work all week long, but full backups would crash every time. Veritas
>support was of no help.
>
>Michael <boing@myrealbox.com> wrote:[color=green]
>>Steve[color=darkred]
>>> These appear to work, but now NDMPD.NLM is eating all the memory - in[/color][/color]
>a recent[color=green][color=darkred]
>>> test this morning NDMPD's share of the memory jumped from 239k to 100mb,
>>> and then slowly reduced back to previous levels again.[/color]
>>
>>Does this actually cause a problem with other applications/user
>>logins/etc.? What I find is that when BE runs a backup, if there's
>>available memory/processing power there to use, BE will use it, but
>>relinquish it when other apps require it.
>>
>>As long as BE *does* release it (which it appears to do in your case)
>>and doesn't affect other apps, then it seems to be working correctly.
>>
>>Michael
>>--
>>"If it jams, force it. If it breaks, you probably
>>needed a new one anyway"
>>
>>* Please post replies via the newsgroup *[/color]
>[/color]