It was the OpenText Technical Alert message sent out November 4, 2013 that drew my attention to memory leaks in DM Server:
In OpenText Document Management, eDOCS Edition (eDOCS DM) 5.3.1, with .NET Framework 4.0 installed on the client and server machines, the DM Server may stop responding. The tracking number for this issue is DM-31701.
The alert suggested installing .NET 4.5 as soon as possible to fix memory leaks.
I searched for known memory leaks in .NET 4.0, but couldn't find reports on any major issues. I then asked OpenText which specifically known issue in .NET 4.0 negatively impacts DM, but their answer was: "We tested with .NET 4.5 and couldn't detect memory leaks. You should install .NET 4.5 as recommended." Uh...
So I installed .NET Framework 4.5.1 on DM servers and started monitoring the memory of the DOCSFusion.exe process. It was soon noticed that memory consumption of DOCSFusion.exe is steadily increasing over time. Here is what I see now on a server:
This particular instance of DOCSFusion.exe was running for 20 days now and it climbed up to using 550 Mb of memory.
The issue was brought to OpenText Support Team's attention. After months of exchanging emails with OpenText Support and sending a ton of server and memory monitoring logs (OpenText has a special tool for this - WatchMemory.exe), I gave up on them admitting and fixing the issue.
This issue may be not critical in your environment, still you may want to keep your eye on it while monitoring your DM servers. The method I use for DOCSFusion.exe remote monitoring is checking the value of Process.WorkingSet64. Below is some C# code.
In OpenText Document Management, eDOCS Edition (eDOCS DM) 5.3.1, with .NET Framework 4.0 installed on the client and server machines, the DM Server may stop responding. The tracking number for this issue is DM-31701.
The alert suggested installing .NET 4.5 as soon as possible to fix memory leaks.
I searched for known memory leaks in .NET 4.0, but couldn't find reports on any major issues. I then asked OpenText which specifically known issue in .NET 4.0 negatively impacts DM, but their answer was: "We tested with .NET 4.5 and couldn't detect memory leaks. You should install .NET 4.5 as recommended." Uh...
So I installed .NET Framework 4.5.1 on DM servers and started monitoring the memory of the DOCSFusion.exe process. It was soon noticed that memory consumption of DOCSFusion.exe is steadily increasing over time. Here is what I see now on a server:
This particular instance of DOCSFusion.exe was running for 20 days now and it climbed up to using 550 Mb of memory.
The issue was brought to OpenText Support Team's attention. After months of exchanging emails with OpenText Support and sending a ton of server and memory monitoring logs (OpenText has a special tool for this - WatchMemory.exe), I gave up on them admitting and fixing the issue.
This issue may be not critical in your environment, still you may want to keep your eye on it while monitoring your DM servers. The method I use for DOCSFusion.exe remote monitoring is checking the value of Process.WorkingSet64. Below is some C# code.
using System.Diagnostics; ... public long MaxMemLimit = 800 * 1024 * 1024; // 800Mb ... var procs = Process.GetProcessesByName(ProcessName, MachineName); if(procs == null || procs.Length == 0) return new TestResult(false, null, subj, string.Format("Process {0} was not found on {1}.", ProcessName, MachineName), null); var mem = procs.Max(p => p.WorkingSet64); var isTestPassed = mem <= MaxMemLimit;
No comments:
Post a Comment