There are several previous conversations on this a few year old but there is a ton of misunderstanding of the App Pool and ERP server behavior in general so a few of my favorite topics…
-
Caching
ERP 10 Server Caches Data. A Lot. More every release. It’s one of the reasons we heavily discourage straight to the db updating and prefer you use BO Methods. There is a cache invalidation system that is tapped into the standard BO Updates so straight SQL will bypass the caching and can cause lots of (not) entertaining side effects.
After a recycle, as each service is called over a few days, a new chunk of memory gets cached. It could be a query structure, it could be actual data such as the list of Users in a system. The point being is that you will see memory grow over time and that is fine. -
‘Memory Leaks’
There can be real memory leaks - both in shipping code as well as in BPMs, functions and the like. In normal usage, these will get cleaned up at the end of a server call. All server objects are cataloged and we iterate through to ensure no one has done something bad. The Disposable trace will note that for you
An example of this scenario is as follows. An warning that the framework cleaned up an undisposed class after the previous operation.
This handles most scenarios fine EXCEPT - long running tasks.
Something that runs a LONG time - maybe MRP - can have a memory leak that can bring a server to it’s knees to finish the task. At the end of that process, the framework cleans up all the loose objects and everything springs back to life happily (Until the next time the task is executed).
I have many chats with customers and partners that have made mistakes in BPMs and this trace has helped them identify issues in their efforts.
And yes, if you see any of these scenarios in the wild without BPMs - log it! We go through and clean these mistakes up from time to time as we find them.
-
App Pool Settings
There are a lot of settings in the IIS App Pool you should walk through and understand. There are numerous options to fit what how you want to have your server behave. There is no one size fits all. Everyone has different needs so spend a little time understanding how IIS behaves so you can apply your preferences onto your system. I’ll call out a few I get into a lot of conversations about.
-
Generate Log Entry
YES - PLEASE. LOG ALL THE THINGS. #KnowledgeIsPower -
ShutDown Time Limit
I assume everyone has been looking at w3wp.exe for some time. When you recycle the app pool, you start a second w3wp and send all new server calls to the new version. The old one sticks around for a while to finish the calls it is handling. Most server calls will fit into the default 90 seconds but what about long Tasks and Queries? MRP running for an hour or more that gets blasted and have to start over. Users get cranky about that for obvious reasons. It’s not unusual to see people allow for hours to trickle down those long running tasks on their task processing servers. This allows for a more stable switch over to the process but does keep memory reserved for a longer time frame. #TradeOffs
If everything finishes in 3 seconds, everyone flips over in that 3 seconds. If it take longer to finish the effort, you run with 2 instances until the time limit or it is done.
I hope this kind of helps. This is one area where grabbing your handy IIS 101 docs are a good investment.