From 451301e75550d44fa3456f69ca38e69abadcee05 Mon Sep 17 00:00:00 2001 From: John Cardinal Date: Thu, 4 Jun 2020 19:33:22 +0000 Subject: [PATCH] --- ayanova/devdocs/todo.txt | 43 +++---------------------------- ayanova/src/views/ops-metrics.vue | 40 ---------------------------- 2 files changed, 3 insertions(+), 80 deletions(-) diff --git a/ayanova/devdocs/todo.txt b/ayanova/devdocs/todo.txt index 3b8fb2fe..c8bb2916 100644 --- a/ayanova/devdocs/todo.txt +++ b/ayanova/devdocs/todo.txt @@ -6,48 +6,11 @@ WIFI change 5g channel to 52,56,60 and 2g channel to 8 recheck before doing as it seems to vary, maybe someone else's is auto switching -############################################################################################### todo: MEMORY / RESOURCE LEAK APPARENT - what exactly is in gc gen0, 1 and 2? They seem to increase then stay high without dropping - can I view the actual objects stored there? - memory consumption seems to rise and rise and stick - STEPS: - For GC, need to execute - Test long run without doing anything see if increases on it's own - Test with unit tests and not seeding much at all see if it increases from unit tests - 1 test caused everything to rise and hold except alloc which dropped to baseline after a number of refreshes of stats - Test burn test but really really long, like 2000 runs or non stop overnight see if it just keeps rising until the end - Test with big gen and see if it goes down on it's own overnight (I don't think it is but can double check) - Find out whats being held in GC-Gen0, Gen1 and 2 imply they will eventually be collected - Review that profiling / metrics doc from Microsoft re .net core 3 https://docs.microsoft.com/en-us/aspnet/core/performance/memory?view=aspnetcore-3.1 - + Wasn't a leak, checked into it + I'm using and logging GC gen0-2 incorrectly and it's really not helping in any way so removing that stat + Keeping the other stats -Calling GC.Collect explicitly: - Should not be done by production ASP.NET Core apps. - Is useful when investigating memory leaks. - When investigating, verifies the GC has removed all dangling objects from memory so memory can be measured. - - Allocated: the amount of memory occupied by managed objects - Working set: The set of pages in the virtual address space of the process that are currently resident in physical memory. The working set shown is the same value Task Manager displays. - -# Ran 5 iterations of integration test, built up some GC gens , triggered collect, no change at all in GC, but Allocated dropped -https://docs.microsoft.com/en-us/dotnet/core/diagnostics/debug-memory-leak -https://docs.microsoft.com/en-us/dotnet/core/diagnostics/dotnet-counters -https://docs.microsoft.com/en-us/dotnet/core/diagnostics/dotnet-dump -https://docs.microsoft.com/en-us/dotnet/core/diagnostics/dotnet-trace - -Might be doing GC Counts incorrectly, they don't sync up with the dotnet-counters tool which shows them drop back to zero regularly when I stop burn test -https://michaelscodingspot.com/ways-to-cause-memory-leaks-in-dotnet/ -https://bennettadelson.wordpress.com/2013/04/11/using-perfview-to-diagnose-a-net-memory-leak-2/ - - -1) Find out if my use of serviceproviderprovider db context is leaking - BY: making a method that can be triggered and does a hella huge number of iterations calling db context to simulate - in metrics controller beside the collect method "hammer" - - - -################################################################################################## todo: Block licensing related queries and view and auth from profile diff --git a/ayanova/src/views/ops-metrics.vue b/ayanova/src/views/ops-metrics.vue index 03549080..d32c1586 100644 --- a/ayanova/src/views/ops-metrics.vue +++ b/ayanova/src/views/ops-metrics.vue @@ -35,13 +35,6 @@ class="my-12" /> - - - @@ -338,39 +331,6 @@ export default { ] }; }, - gcAllChartData() { - return { - datasets: [ - { - label: "GC Gen0", - borderColor: CHART_PALETTE.blue, - fill: false, - radius: 0, - hoverRadius: 10, - hitRadius: 4, - data: this.memcpu.gen0 - }, - { - label: "GC Gen1", - borderColor: CHART_PALETTE.cyan, - fill: false, - radius: 0, - hoverRadius: 10, - hitRadius: 4, - data: this.memcpu.gen1 - }, - { - label: "GC Gen2", - borderColor: CHART_PALETTE.black, - fill: false, - radius: 0, - hoverRadius: 10, - hitRadius: 4, - data: this.memcpu.gen2 - } - ] - }; - }, memAllChartData() { return { datasets: [