Hello Leo. On Sun, 25 Nov 2018 at 08:29, Leo Donahue <donahu...@gmail.com> wrote:
> Maybe this helps? > > SER10-J > > https://wiki.sei.cmu.edu/confluence/pages/viewpage.action?pageId=88487787 > > Still early days yet, but I think a heart-felt thank you might be in order here. Resetting the output stream after writing may have released transmitters that remain cached after writing. Doing this appears to have made the transmitters eligible of garbage collection. The number of "Live Objects" rarely goes above 4 and the "Live Bytes" column rarely goes into three figures for any sample displayed in the objects view on the profiler. I still see the number of "Allocated Objects" appears to rise without limit, and so I'm not sure what this column is displaying: is it the total number of objects created during the time that the view has been sampling? I notice that my CPU's have become considerably more active (all four of them now run at about 80% instead of at about 30%), but I put this down to the extra load being generated by the increased activity of the garbage collector. I also notice a significant increase in the amount of "socket resetting" required by my application. Again, I believe this is due to the garbage collectors staking the CPU's away from my processes which allow only a small window of delay before closing the current socket and creating a new socket to replace it; this is a designed intent, and one that may add even more load onto the CPU's. I do still see memory rising slowly on the system monitor, and so I deduce that I haven't eliminated all my memory leak problems with this apparent fix... pity. The main thing is that this appears to be progress that wouldn't have happened without your tip. Perhaps, however, I still have more questions to ask. Thank you, Owen.
