I’m trying to find a work-around for the memory limitation (hanging/crashing the system) of the Smart Inspect Console when using TCP/IP and live logging. Yes, I know it is not meant for production and to not leave it open; but our users will do just that no matter now many times we tell them.
Reading through older posts I found your messages regarding adding in a periodic call to SiAuto.Main.ClearLog to clear the console to reduce the memory consumption.
I added this as a side thread to my main application as well as to another mini-app we use that also logs . In my test case right now I am clearing the log every hour (this was proof of concept so the time period was kept short. The mini app runs such that the main app is continuously working and logging, set up as a stress test if you will.
I used SysInternals to track the memory use and after running for two hours I saw no decrease in the memory footprint, only a gradual increase.
At this point (CLEAR 2x) I stopped the mini app thinking the console may need idle time to allow for possible garbage collection and waiting with the main app idle for another hour to trigger one last ClearAll. The memory footprint did not change, at least not as much as I expected it to.
Working Set Private Bytes Virtual Size Start 21,756 15,156 134,076 Clear 1x 135,172 143.2620 261,924 Clear 2x 202,280 210,016 328,548 STOP App, GC 203,984 210,916 329,444 1hr after STOP 202,048 208,472 327,012
We have one long-lived main trace object and use many other individual trace objects (some short-lived, and some long in various threads) as part of our application. The thread that waits to clear the console uses only the main trace object but in watching the SI console, all messages are cleared so I don’t think I need to call ClearLog from all of my trace objects, just one to trigger the clear.
This technique of periodically clearing the console does not fix the long-term memory use of the console application. If I am missing a step or need to do something, please let me know.