On our iService web server, we have noticed that the worker pool is consuming more than 1GB of memory. We can see this in the Task Manager for the w3wp.exe process. How can we reduce the amount of memory used?
A worker pool is an assigned application space for one or more web sites to run their application code in, and every web application and situation is different. However, you should rarely have a worker pool process (w3wp.exe) using more than 1GB of memory.
ASP.NET requires a certain amount of libraries to be loaded and resident in memory during execution, which is why most of the services iServiceCRM utilizes are expressed as web services. By utilizing the web server for application management, these libraries remain resident rather than being required to be loaded every time a request comes in. This results in reduced load times for agents and customers because the web server leaves at least the minimal libraries resident, rather than swap them out as a threaded application would each time a thread was created or terminated.
We have noticed a tendency for the w3wp.exe processes to gain memory, rather than lose it. In theory, ASP.NET handles what programmers refer to as garbage collection internally, leaving the programmers with only having to ensure that memory which is no longer required is also no longer referenced anywhere... unfortunately in practice, it seems that it also errors on the side of keeping memory resident longer than might really be necessary, especially within worker pools for IIS.
We have tried a number of changes to the worker pool settings within IIS, and at present we find that iServiceCRM works best for us with the following settings:
1) Make sure that the worker pool which is handling the iServiceCRM web site is handling ONLY the iServiceCRM web site. If your web server handles more than one web site, the other web sites should be in a separate pool. This is also necessary if you have a web application which requires a different version of ASP.NET than iServiceCRM currently requires (.NET 3.5)
2) In the Recycling pane of the worker pool settings, we have the worker pool set to recycle when used memory reaches 1024 MB and after 120 minutes.
Because worker pools will complete in-process threads before actually shutting down a worker pool, the 120 minute recycle is probably a bit aggressive, but agents don't notice because of the way worker pools are launched -- when the recycle time occurs, a new thread starts to handle new incoming requests, but existing and/or running requests complete with the existing old thread. Once the old thread has no more pending requests, it terminates, thus releasing the memory allocated to it.
Another option is to check the Web Garden section of the Performance pane. The only down side is that it will mean that you have multiple pools resident in memory at the same time. If memory is at a premium, this might be a concern, but if not, having 2 or more worker pools as your maximum will help with responsiveness by ensuring that there is always at least one worker pool ready to take on new requests, even if another is in the process of recycling.
Because of the way iServiceCRM works, no single agent request or action should require 1GB of memory usage, but because ASP.NET is reluctant to release memory once used, a worker pool that doesn't recycle may grow large, especially if a lot of requests come in within a short period of time. These settings help keep things under control and maximize resource usage.
We suggest that on-premise clients monitor memory and cpu utilization. We utilized EventSentry for our server monitoring and are an authorized reseller for that product. Contact our sales department (firstname.lastname@example.org) for more information about that solution.
In addition, if you have other applications running on the iServiceCRM web server you might try http://iispeek.com/index.php to help you isolate the application that is consuming memory.