Bojan Sumljak wrote:
And nsrjob has this values:
77 ? 27161 root 152 20 1400M 1377M run 4156:33 14.23 14.20 nsrjobd
Do you believe in euthanasia? It doesn't matter if you don't - just kill it. Simply find right time and stop server. Then delete /nsr/res/jobsdb and start backup server again. This will buy some time for you.
I've killed it and removed the jobsd, after that ccr works and for now I didn't have any time-outs.
I am monitoring the nsrjobd to see how much time do I have before it gets to 1.5Gb again...
Let me continue with my monologue. Why monologue? Because I have ticket opened for almost 3 months with no feedback (except initial give us everything-you-got request to run nsrget). I have to be fair and say that I have ticket opened over EMC partner, but they assure me that they do not get feedback from EMC engineering. With that in mind, I can assume following:
a) EMC does like partner
b) This issue is bigger than I thought initially
I'm not going to guess as that doesn't help, but I will say that it IS bigger than I originally thought as I can confirm that I see the same thing on AIX based backup server. And I suspect Linux too; I recently updated those to 126.96.36.199, but at different times and top -p <nsrjobd pid> shows that those started first have larger memory usage (all those servers are small and share pretty similar load - difference should not impact memory usage). I also compared this against one remaining NW7 server on AIX; memory usage is 130M opposed to NW8 which grabbed 1.46G while running since 15th January. It is fair to say that NW8.0.x sucks - sucking memory via nsrjobd
I would liek to appolgize for the delay in this issue being resolved and I would like to see if I can assist in getting this problem pushed to resolution.
In order to do that I will need some information emailed to me. Please send me the following information:
The EMC service request, if you have
Your partner company name
Your primary contact at the partner company
I have a fair amount of information from this post. If I need more, I will let you know.
I can tell you that there is a technical note open for this issue and it is being investigated by NetWorker engineering. I would like to make sure you are included in this process, if possible.
Again, my appologizes for this issue not being taken care for you.
188.8.131.52 is a bit behind in respect to current patch level (for same code tree that would be 184.108.40.206). As for error itself, if this is again on NMDA side, I know for sure this is fixed in NMDA 1.5 as I do not get an issue with it. However, if you get this with file system backup, then chances are that you really have an error somewhere like hanging NFS on the client (easiest way to check is via bdf command).
Thanks for quick answers. As i heard from customer we will go directly to 8.1 soon.
Mit freundlichen Grüssen / Best regards
ISD - Industrie Service für Datenverarbeitung GmbH
Technical Service Center (TSC)
Senior Systems Engineer
Phone +49 621 6361 993
Sitz der Gesellschaft: 67063 Ludwigshafen am Rhein
Registergericht: Amtsgericht Ludwigshafen
Handelsregisternummer: HRB 4595
Geschäftsführer: Peter Krauß (Sprecher der Geschäftsführung), Ralf Trautz, Rouven Heim, Herbert Schenkel
Der Inhalt dieser E-Mail Nachricht von ISD GmbH ist ausschließlich für deren Empfänger bestimmt. Die Verwendung dieser Nachricht durch Dritte ist verboten. Falls Sie diese E-Mail versehentlich erhalten haben, löschen Sie sie bitte, ohne deren Inhalte, auch nur teilweise, zu lesen, zu benutzen, zu kopieren oder an Dritte weiterzuleiten. ISD GmbH übernimmt keinerlei Haftung für Schäden, die aus E-Mail Kommunikation entstehen.
Von: Hrvoje Crvelin
Gesendet: Montag, 29. September 2014 15:54
An: Anastassiou, Andreas
Betreff: Re: - nsrjobd memory leak in NW8
nsrjobd memory leak in NW8
reply from Hrvoje Crvelin<https://community.emc.com/people/ble?et=watches.email.thread> in NetWorker Support Forum - View the full discussion<https://community.emc.com/message/840547?et=watches.email.thread#840547>