Server Management (Insight Manager 7)
1822147 Members
4007 Online
109640 Solutions
New Discussion юеВ

Memory leak ??

 
Ayman Altounji
Valued Contributor

Memory leak ??

Hi !!

I?ve just installed IM7 on a Compaq proliant 400 running windows 2000 pro.
I also use a MS SQL 7 on an other Compaq server (DL 380) running Windows NT 4 server. When the IM7 service has been running for a day or so, the process "java.exe" starts eating memory and after while windows says that it?s out of viritual memory (394 mb of physical memory and over 700 Mb of viritual memory). On the same machine i've got Cim 5.3 and Optivity NMS 9.2.0.2 running (not the server part of Optivity). Any ideas about what could be wrong ???

./Fredrik
13 REPLIES 13
Ayman Altounji
Valued Contributor

Re: Memory leak ??

YES! I was meaning to post the same message. I have CIM7, with SQL7, NT 4.0 (sp6a) on a 1600r. I experienced the same issue. You can sit and watch the memory climb with the browser open. Once you close the browser, it stops at the memory allocation that it's at and stays there. If you open the browser backup, you can see the java.exe climb again. The trick here is to not use the browser on the CIM server itself. I would connect from the workstation and there isn't an issue. IF you're getting the virtual memory error, you probably have had the browser (CIMXE console) open for quite a while.
Ayman Altounji
Valued Contributor

Re: Memory leak ??

What version of Internet Explorer are you running? In addition, do you have multiple versions of the Sun Java Plug-in installed? I would suggest opening a support case on this - this is not a known issue.

Thanks.
Ayman Altounji
Valued Contributor

Re: Memory leak ??

Hi !

I tried not to use explorer on the IM7 host, but the java.exe process is still climbing. On my workstation i use iexplore 5.5 sp2. when i start the IM7 process, java.exe climb to about 40MB and stays there for a while, then when i start a browser on an other machine, i can surf for a while, then it starts to climb again.

./Fredrik
Ayman Altounji
Valued Contributor

Re: Memory leak ??

I highly suggest calling 800-OK-COMPAQ and opening a support case on this. This should not be happening, and it is to complex to debug in a forum.

Thanks.
Ayman Altounji
Valued Contributor

Re: Memory leak ??

I am running IE 5.5. I don't have any other previous java installations.

Fredrik - You may have to close the browser on the server, run the "kill" utility to stop the java.exe. Then don't open it again on the server :-). As far as your workstation, I am using XP and don't even see java.exe running in the task manager. I do have a penguin down in the corner, though.
Ayman Altounji
Valued Contributor

Re: Memory leak ??

I am trying something with this. I saw other people getting errors when they had port conflicts. I am running IIS on my CIM7 and am thinking that it might be conflicting with port 80 that it performs the http discovery on. I turned off the IIS and disabled it. I am going to watch it to see what happens. stay tuned... Oh, and, uh, Tech support knew less than I did about CIM7!
Ayman Altounji
Valued Contributor

Re: Memory leak ??

I'll follow up with tech support, but do you have an open case number?

In the past, we have seen issues with Insight Manager XE where if you completely uninstalled and reinstalled SNMP for some reason while CIMXE/CIM7 is installed, then pointers in the OS can get messed up. Basicallly, you have to reinstall Insight Manager in that case.

Another item that has come up in the past was where the server running Insight Manager 7/XE could not connect to a DNS or WINS server. We do numerous calls to an API that makes a call similar to NSLOOKUP to retrieve a device's name. If the Insight Manager server can not ever connect to it, then memory usage grew (in an environment with NO name resolution at all).

Could one of these be your situation?

Thanks.
Ayman Altounji
Valued Contributor

Re: Memory leak ??

I have the same problem here on a DL360 with 384 MB memory, Win NT 4.0 with sp6a (Dutch version), IE 5.5 with sp2; the java.exe is eating all the memory; both when i use the browser either on the server or on a workstation.
Any ideas ??
Thanks, best regards,
Bart van Reems
Netherlands
Ayman Altounji
Valued Contributor

Re: Memory leak ??

I also have the same problem: java.exe eating all the memory up. Is upgrading to java 1.4 going to help? I'm running NT4 Sp6a IE6.

Regards,

Joe
Ayman Altounji
Valued Contributor

Re: Memory leak ??

Compaq is ignoring this issue. IT HAS BEEN A KNOW ISSUE SINCE XE 2.1! Java is leaking resources!
Bretttt
Occasional Advisor

Re: Memory leak ??

hmmm - this is the same problem I just posted about! Is there a fix for this yet? (12 months later)
Brett Boone
Frequent Advisor

Re: Memory leak ??

I have had the same issue since August of last year. I have had a case opened w/ Compaq the entire time. This issue is known by the engineering team, but they have not been able to duplicate it in their test lab. They are coming onsite tomorrow to troubleshoot onsite. If we make any progress, i will let everyone know.
Brett Boone
Frequent Advisor

Re: Memory leak ??

Compaq engineers and I are 99.9% sure that we have found the root cause of the java memory leak. We believe that it is caused from servers that are/aren't in the database having incorrect snmp settings assigned in the trap and security tabs. With the incorrect settings and without 127.0.0.1 (local loopback adapter) set in the snmp properties, the server will send authentication failure traps to the console; which would flood IM7 and make java.exe rise with memory consumption. After running a debug tool such as network monitor to monitor the snmp traps coming in; we realized which servers were sending all the authentication failures as i described and fixed the snmp settings to the correct values.

All in all make sure that (ALL) servers in your environment have the correct SNMP settings. This would be the correct name/ip address of the IM7 server and the (read-only) community string for the trap tab. Also you will need the name/ip address and the local loopback adapter address (127.0.0.1) along w/ the read-only and read-write community strings on the security tab set correctly. Until these items were updated on each server in our environment, the memory leak still existed.