This commit is contained in:
2020-06-04 19:33:22 +00:00
parent 490a275308
commit 451301e755
2 changed files with 3 additions and 80 deletions

View File

@@ -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

View File

@@ -35,13 +35,6 @@
class="my-12"
/>
</v-col>
<v-col cols="12">
<gz-chart-line
:chartData="gcAllChartData"
:options="timeLineChartOptions"
class="my-12"
/>
</v-col>
</v-tab-item>
<v-tab-item>
<v-col cols="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: [