Cool thread with steps (windbg) tooling and graphs: this is how you approach problem solving.
Easiest to read: [WayBack] Thread by @Nick_Craver: “Well hello there memory leak…let’s see what you are. It’s times when I type !dumpheap without an argument that cals. Alrighty, let’s see what these little guys are: Quite a bit of repetition in here – let’s root some of the […]”
Twitter thread below the fold.
[WayBack] Nick Craver on Twitter: “So let’s form our dictionary in batches EF Core will load, like this. We can lower our SQL roundtrips to n / 1000 + relevant changes. It’s more SQL trips than our original 1, but we aren’t needlessly loading a million users into memory. We load about 0.3% of that instead.… https://t.co/wgHpWgCoJH”
Tooling:
- before/after graphs of
- memory usage graphs
- CPU usage
- knowing the 85k threshold for the large object heap
- basic built-in windbg Commands | Microsoft Docs [WayBack]
- windbg
SOS.dll
extension commands [WayBack] :!dumpheap
!dumpobj
(usually abbreviated as!do
)
- [WayBack] MiniProfiler: A simple but effective mini-profiler for .NET and Ruby (and Go and Node.js)
Related: Some notes/links on Windows Debugging CLR applications
A good WinDbg introduction is [WayBack] Getting Started with WinDbg (User-Mode) | Microsoft Docs.
Note that temp tables in SQL Server might look nice, but actually do not scale well: [WayBack] Lucas Trzesniewski on Twitter: “I’ve found out the following massively improves performance over queries with an IN clause with lots of parameters: – Open a transaction – Create a temp table – Bulk insert your IDs into the temp table – Inner join your query on the temp table And you only make a single query.… https://t.co/anwGSrxRqh”
–jeroen