This commit is contained in:
@@ -6,49 +6,12 @@ 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
|
recheck before doing as it seems to vary, maybe someone else's is auto switching
|
||||||
|
|
||||||
|
|
||||||
###############################################################################################
|
|
||||||
todo: MEMORY / RESOURCE LEAK APPARENT
|
todo: MEMORY / RESOURCE LEAK APPARENT
|
||||||
what exactly is in gc gen0, 1 and 2? They seem to increase then stay high without dropping
|
Wasn't a leak, checked into it
|
||||||
can I view the actual objects stored there?
|
I'm using and logging GC gen0-2 incorrectly and it's really not helping in any way so removing that stat
|
||||||
memory consumption seems to rise and rise and stick
|
Keeping the other stats
|
||||||
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
|
|
||||||
|
|
||||||
|
|
||||||
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
|
todo: Block licensing related queries and view and auth from profile
|
||||||
|
|
||||||
|
|
||||||
|
|||||||
@@ -35,13 +35,6 @@
|
|||||||
class="my-12"
|
class="my-12"
|
||||||
/>
|
/>
|
||||||
</v-col>
|
</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-tab-item>
|
<v-tab-item>
|
||||||
<v-col cols="12">
|
<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() {
|
memAllChartData() {
|
||||||
return {
|
return {
|
||||||
datasets: [
|
datasets: [
|
||||||
|
|||||||
Reference in New Issue
Block a user