Thee_oddball
07-03-2011, 05:20 PM
It turns out the gcConcurrent setting does not change which garbage collector loads. gcConcurrent only has an impact on the workstation (MsCorWks.dll) implementation of the garbage collector (it is effectively ignored by the server implementation), and furthermore only changes the GC behavior on multiprocessor machines.
With the setting enabled the garbage collector uses an additional thread to build a graph of unreachable objects. The rule of thumb is, gcConcurrent=”true” (default setting) will provide for a more responsive application, but can also let the working set (memory usage) grow larger. You’d have to carefully test an application to see if disabling gcConcurrent actually helps an application’s performance or memory usage. The most detailed source of information I’ve found in one place on this subject is Jeffrey Richter’s book.
in your root folder of steam COD you will find the launcherexe config file open it up and change gcconcurrent from true to false and see if your server still suffers from the eventually overload and lag out that happens after it has been running for a while.
S!
With the setting enabled the garbage collector uses an additional thread to build a graph of unreachable objects. The rule of thumb is, gcConcurrent=”true” (default setting) will provide for a more responsive application, but can also let the working set (memory usage) grow larger. You’d have to carefully test an application to see if disabling gcConcurrent actually helps an application’s performance or memory usage. The most detailed source of information I’ve found in one place on this subject is Jeffrey Richter’s book.
in your root folder of steam COD you will find the launcherexe config file open it up and change gcconcurrent from true to false and see if your server still suffers from the eventually overload and lag out that happens after it has been running for a while.
S!