In my previous blog post ( SQL Server memory leaks ), I explained how to "heap!" Using the command module to identify which leaks memory. Sometimes we use "! D" command to find memory model or use the search command (s) can not find the cause of display memory.
In this case, we can use the Debug Diagnostic Tools or UMDH to track memory leaks. This blog post explains how to use the Debug Diagnostics Tools to identify memory leaks.
Download and install the Debug Diagnostic Tools from http://www.microsoft.com/en-us/download/details.aspx?id=26798
1. targeting Tools, "Options" -> " Preferences", select "Record call stacks immediately when monitoring the leaks ".
2. Navigate to the "rules" tab and select "add rule".
3. Select "Naive (non .Net) memory leak and handle leak".
4. Select SQL Server or any process for tracking memory leaks.
5. Click "Next" and leave the default option (when the rule is completed or fails, you can select "auto-unload Leak track") .
6. Click "Next" and activate the rule now.
7.Leaktrack.dll has been added to the process for tracking the distribution of years.
8. Now you can wait for leaks again.
|
1
2
3
4
5
6
7
|
-- If you are learning how to troubleshoot SQL Server memory leak follow the steps which we followed in previous post (https://mssqlwiki.com/2012/12/04/sql-server-memory-leak/)to leak the memory.
-- Download HeapLeak.dll from this link.
-- Create an extended stored procedure in SQL Server
sp_addextendedproc ‘HeapLeak’,‘C:\HeapLeakdll\HeapLeak.dll’
-- Let us execute this Extended SP 30 times and leak memory.
exec
HeapLeak
go 30
|
9. When you suspect a memory leak, navigate to the "rules", and by right-clicking the user to perform a complete dump "Leak rule".
10. After the dump is captured, navigate to Advanced Analysis tab, add a data file and select the dump we generate.
11. The targeting Tools, "Options" -> " set the symbol path for analysis". The default Microsoft symbol path below.
srv * c: \ Websymbols * http : //msdl.microsoft.com/download/symbols; c: \ Release
Important: Using SQL Server is loaded into the symbol path in the DLL substitute c: \ Release (optional)
12 in the analysis of available scripts, select memory pressure analyzers (memory analysis.asp).
13. Click "Start Analysis".
14. The time spent loading symbol analysis may take a little time. When the analysis is complete, it will generate and open an HTML report. The HTML report stored by default in C: \ Program Files \ DebugDiag \ Reports \ may be used for subsequent reference.
I've attached a sample report collected when using heapleak.dll memory leak, here http://sdrv.ms/TH1qfR. You can use it as a reference.
Debug Diagnostic Tool memory pressure analyzer generates reports and analysts following table summarizes the memory.
|
1
2
3
4
5
6
7
|
sqlservr.exe__…………dmp
Virtual Memory Analysis Report
Heap Analysis Report
Leak Analysis Report
Outstanding allocation summary
Detailed module report (Memory)
Detailed module report (Handles)
|
15. The analysis is summarized in a report which module a good part of the positioning leak memory. Review the following report.
16. The report has clearly shown that there is 255MB HeapLeak.dll significant assignment. In heapleak.dll in "Sub" function for allocating the memory 23 at the offset.
17. Review the summary of virtual memory. It gives a complete picture about where the virtual memory address distribution holes home. The following summary is retained in 1.57GB, which is normal in 32-bit SQL Server years, but there are 272.94MB local heap memory is not normal.
View the heap summary, there are 50 stacks.
18. Now see significant allocation summary. It gives the total number of modules 10 before the distribution and size distribution. Occupancy 255.6MB in size of 26182 in the following summary HeapLeak.
Note: In this report where it is HeapLeak, but in practice it may be any leaks memory module.
19. You can also view detailed reporting module (Memory). It gives the memory allocation, (if you set the symbol for all loaded modules) from each module and the source line and a function to allocate memory.
We now confirm that 14 positions are assigned a 255MB, and unreleased HeapLeak.dll in the Sub line number for the function. This report also gives you callstack example that shows when the function allocates memory code paths. Reference example HTML report file http://sdrv.ms/TH1qfR .