K2server.exe memory usage

It is highly recommended that a more advanced tool is used for diagnosing memory usage of the K2Server (and all other .NET applications) than the normal Windows Task Manager. What Task Manager reports in terms of memory usage is called the Working Set. This is the amount of physical RAM allocated to the process. To complicate matters, some of the memory in the Working Set may be shared with other processes, including parts of the .NET runtime. Therefore, there is double counting in Task Manager’s memory usage column. Windows may also allocate additional memory to the process in case it may be needed later. For these reasons, the Working Set may overstate the real memory requirements of the application and the Task Manager not suitable for measuring memory usage.

 We recommend the use of ‘Perfmon’. The following counters are of interest when diagnosing memory problems:

1. 
   
2. Private Bytes/K2Server.exe
   
3. Working Set/K2Server.exe (This is the figure reported by the Task Manager)
   
4. .NET CLR Memory/#Bytes in all Heaps

It is possible to trim the Working Set (This functionality is not something you would build into an application because the .NET runtime should manage this for performance reasons).

You can use .NET Memory Profiler (3rd party tool - 14 day free trial) to analyze the memory usage of the K2Server. This application also allows you to trim the Working Set at the click of a button. The K2Server memory usage will immediately drop down to the level when it was started. Windows not only trims unneeded memory from the allocation, but also pages memory to disk where possible. The Working Set does not include memory paged to disk.

Private Bytes is the most useful figure when you want to know much memory the K2Server is using. This is memory allocated to the K2Server process that cannot be shared by other processes. Note that the Private Bytes may not all be in physical memory but can also be swapped to disk. If they are swapped to disk, then they aren’t having much impact on other applications.

Here are a few further observations:

1. 
   
2. .Net Runtime/Windows generally does a good job of memory management. High figures in Task Manager should not be a concern if the system is running well.
   
3. .NET applications have a high memory footprint relative to most native (unmanaged) code applications. This isn’t too important on systems with plenty of RAM, but becomes a major issue in constrained environments like Terminal Server or Citrix clients.
   
4. What really counts is performance and user satisfaction. Memory usage is one of many factors that make up performance, and it’s important to keep it in perspective. Keep an eye on the available physical memory on Task Manager's Performance tab; if this reports hundreds of MB free, the K2Server is not really stressing the system. It is possible that the garbage collector finds all the free memory when ‘System.GC.Collect’ is called but elected not to return that memory to Windows. This happens when there is plenty of free memory available to the system so there is no point wasting CPU cycles to free up memory that (a) isn't needed by anything else and (b) might well be needed again by the K2Server process.
   
5. Finally, there isn't much developers can do about the memory footprint of the .NET runtime. This is down to the .NET runtime.

More information can be found here: http://msdn.microsoft.com/msdnmag/issues/1100/gci/

If you think that your K2Server is suffering from a memory leak log a ticket with your local support and provide a Perfmon trace and all error/log files. A SQL Profiler trace would also be helpful.

Hello,

It has been a while, but I'm back on this topic (I also logged a support ticket for this)

If I take into account the recommendations from the post above: our process design is only not so good because we don't follow the rules in the "Resist the temptation to store all your data in K2.net data fields". However, it is not the data fields that contain much data, it are the xml fields that contain lots of data.(= approx 22 xml fields defined, 3or4 are filled based on parameters, and contain each 2kb of data) We currently have 11800 instances, containing 994 running instances.

If I use memory analysing tools, the only thing that shows up is System.Byte[] that rises.

We are "lucky" in a way because each month we have to reboot the server due to patch/SOX complaince reasons. After the reboot k2server.exe is approx 60MB, after 4 weeks: 1.1GB. What actually causes the raise ? are it new workflow instances that are launched ? or are it running processeses? instances in error ?

I'm thinking of making a scheduled task that restarts each night the k2server.exe process ... because the coming year the growth of instances could grow by a factor of 2