12-09-2013 02:04 AM
after upgrading three sim servers to the latest 7.2.2 also the VCRM was updated to this version.
The SIM servers are virtual machines with 16 GB memory and 4 cpu running on Windows 2008 R2 SP1.
Two are running with a local sql installation because of less clients.
One has a remote sql DB.
Now on all three servers we see extremly memory usage for the VCRM, which was not observed with the older version 7.2.0.
The memory usage goes up to 15 GB memory, in conjunction with the mxdoaminmgr with about 1,8 GB memory absolute slow down of the server.
We are receiving such events:
Log Name: System
Date: 09.12.2013 10:20:20
Event ID: 2004
Task Category: Resource Exhaustion Diagnosis Events
Keywords: Events related to exhaustion of system commit limit (virtual memory).
Windows successfully diagnosed a low virtual memory condition. The following programs consumed the most virtual memory: cpqsrhmo.exe (1228) consumed 15086669824 bytes, mxdomainmgr.exe (3084) consumed 1800044544 bytes, and mxdtf.exe (1500) consumed 219762688 bytes.
Because this behaviour is on three servers since the upgrade i fear we have a bug in the VCRM 7.2.2.
Restarting the VCRM takes also a tremendous time to finish.
What could be the reason for that?
05-20-2014 05:15 PM - edited 05-20-2014 05:16 PM
I've got the same problem with version 7.3.2 on a machine with 16 GB memory and 4 CPUs running Windows 2008 R2.
06-02-2014 05:57 AM
I've got the same problem with version 7.3.0, installed patchs 001 to 011, on a machine with 20 GB memory and 4 CPUs, running Windows Server 2008 Standard x64 SP2 (VM).
a week ago
Do you have the automatic download enabled? How many SPP's do you have loaded? I 've used the VCRM for many years and never had this problem. So perhaps it's that you have a lot of files in the VCRM, i use no more than 3 baselines.
My setup uses about 8 to 9 Gb max on a 12 Gb machine. You could try to disable the autodownload cleanup the directory and only unpack the SPP's you need in the VCRM directory. See how the memory usage evolves.