>computation error of some sort No that isn't a computation error. I watched the windows perfmon counters rise to that in a real-time graph. Next time I'll take a memory dump and send the 20 GB file over to Progress.
What bothers me is that the memory isn't listed in the ABL sessions that are running this "SSRS-shipping-analysis-report". As near as I can tell, the report is pulling in 10,000,000 rows of data from the database, and storing these into a temp-table. This is bad enough but the moment that the whole mess is serialized and sent back to APSV client, it immediately doubles the memory usage (in a span of 30 seconds it consumes about 10 more GB). This is not a well-designed workflow to say the least. But it poses some interesting questions about how to manage & monitor PASOE when the code is poorly written (yes, it happens). It seems fairly clear that the TT/DS memory usage is
excluded from the "session memory (KB)" in the OEE console. Perhaps there should be another column that shows the current TT/DS data size. It isn't an interesting number in itself until the AVM decides it needs to pull it all into memory at once (eg. for whatever reason, like scanning it on a different index, or serializing it back to the remote APSV client). When that happens it seems to "dim the lights". Please let me know if there is any easy way to monitor the ongoing TT/DS memory activity of a session at a high level. I might use logical disk counters in perfmon. That is a round-about approach - it would be nice if OEE or ABL had a metric for the amount of TT/DS data in use by a session. I found a whole whitepaper on this but it looks like it gets down to an extremely fine level of detail, which I don't really need:
www.pugchallenge.eu/.../temp-tables-pug-emea-nov-2017_v4--dan-foreman.pdf
