D
dbeavon
Guest
An update: I was able to get the resident size (working set) to go back down to 100 MB if I run another greedy program that puts pressure on the memory of the OS. This is a relief, and I suppose that most of my concerns will be mitigated by having an extremely large pagefile. But I don't think it is the whole answer. IE. If I put pressure on memory then the working set drops, however I see that the "commit size" is never decreasing. That means we will probably fill up the pagefile at some point, no matter how large it may be. It was the writing of the process memory-dump that caused my concerns. The size of that memory-dump corresponds to the "commit size" of the process. The act of writing the memory dump will transfer *all* committed memory to a file (ie. both the resident stuff or the stuff that has been swapped to the pagefile). It is pretty clear that these memory dumps are unreasonably big, and the committed memory is never getting released (even when the system is under memory pressure, and the ABL sessions have all been trimmed from the agent). Since it has only been a few days, I will make sure there is plenty of space in the pagefile and continue to monitor. Perhaps the "commit size" of the agent process will stop growing. We should be fine as long as it stops growing. I am still assuming that the problem is *not* with our custom code, because the "commit size" is large even after trimming all of the ABL sessions (which are responsible for hosting our custom code ).
Continue reading...
Continue reading...