Posts Tagged ‘memory leak’

Debugging memory Leaks using Debug diagnostic tool.

Posted by Karthick P.K on December 6, 2012

In my previous post (SQL Server memory leak ) I explained how to identify the modules which are leaking the memory using ‘!heap’ commands. Sometimes we may not be able to find the cause by displaying the memory using ‘!d’ commands to find the patterns or using search memory commands (s).

In such scenarios we can use Debug Diagnostic Tool or UMDH to track memory leaks. This blog will explain how to identify the memory leaks using Debug diagnostics tools.

Download and install Debug Diagnostic Tool from http://www.microsoft.com/en-us/download/details.aspx?id=26798

1. Go to ToolsàOptions ->Preferences àSelect Record call stacks immediately when monitoring the leaks.

2. Go to the rules tab and select add rule.

3. Choose Native (non .Net) memory leak and handle leak.

4. Select the SQL Server or any process which has to be tracked for memory leak.

5. Click next and leave the default options (you can choose auto-unload Leak track when rule is completed or deactivated).

6. Click next and Activate the rule now.

7. Leaktrack.dll would have loaded to the process for which we are tracking the allocations.

8. Now you can wait for the leak to happen again.

{

–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. Once you suspect memory is leaked. Go to the rules and take a full user dump by right clicking the Leak rule.

10. After the dump is captured , go to the advanced analysis tab, Add data files and select the dump which we generated.

11. Go to ToolsàOptions ->set the symbol path for analysis. Default Microsoft symbol path is below.

srv*c:\Websymbols*http://msdl.microsoft.com/download/symbols;c:\Release

Important: Replace c:\Release with symbol path of dll’s which you have loaded in SQL Server (optional)

11. In the available analysis script select memory pressure analyzers (memory analysis.asp).

12. Click start analysis.

13. Analysis might take a while depending on time it takes to load the symbols. Once the analysis is completed it would generate and open a HTML report.

This HTML report is stored in C:\Program Files\DebugDiag\Reports\ by default and can be used for later reference.

I have attached a sample report which I collected when leaking memory using heapleak.dll in This link. You can use it for reference.

Report generated by debug diagnostic tool memory pressure analyzer will have the analysis summary and below Table Of Contents

sqlservr.exe__…………dmp

Virtual Memory Analysis Report

Heap Analysis Report

Leak Analysis Report

Outstanding allocation summary

Detailed module report (Memory)

Detailed module report (Handles)

14. Analysis summary is good portion in the report to start with and would give the module which is leaking the memory. Look at the below report.

15. Report has clearly indicated HeapLeak.dll has 255 MB of outstanding allocations. In heapleak.dll “Sub“ is the function which allocated this memory at offset 23.

16. Look at the virtual memory summary. It gives complete picture about memory distribution in the virtual address space. In the below summary memory reserved is 1.57 GB which is normal in 32-Bit SQL Server, but native heaps is 272.94 MB which is not normal.

Look at the heap summary there are 50 heaps.

17. Now look at the Outstanding allocation summary. It gives top 10 modules by allocation count and allocation size. In below summary HeapLeak has 26,182 allocations with size of 255.6 MB.

Note: In this report it is HeapLeak but in real time it might be any module which is leaking the memory

18. You can also look at detailed module report(Memory). It gives the memory allocation from each module along with function and source line which allocated the memory (If you set the symbols for all the modules loaded).

By now we are sure that sub function in HeapLeak.dll has allocated 255 MB in line number 14 and has not released. The report also gives you the callstack samples that show the code path when functions was doing allocations. Refer This sample HTML report file.

If you liked this post, do like us on Facebook at https://www.facebook.com/mssqlwiki , join our Facebook group https://www.facebook.com/mssqlwiki#!/groups/454762937884205/ and post your SQL Server questions to get answered by experts.

SQL Server 2012 Memory

Troubleshooting SQL Server Memory

A significant part of SQL Server process memory has been paged out

Thank you,

Karthick P.K |My Facebook Page |My Site| Blog space| Twitter

Posted in Debugging, Memory, Performance, SQL Server memory | Tagged: debug diagnostics tool memory leak, how to find a leak, memory leak, memory leak in, SQLServer memory leaks, what are memory leaks | 5 Comments »

SQL Server memory leak

Posted by Karthick P.K on December 4, 2012

What is memory leak?

When a process allocates memory it is supposed to de-allocate it and release it back to OS. If it misses to de-allocate the memory due to flaw in code it is called as leak and It can cause memory pressure both to the operating system and application.

Myth about SQL Server memory leak

SQL Server memory management is designed to dynamically grow and shrink its memory based on the amount of available memory on the system and Max server memory setting in SQLServer.

Many times system admins look at the memory usage of SQLServer and assume SQLServer is leaking memory if they find SQL Server memory usage is high.

This is incorrect SQL Server is server based application and its memory manager is designed in such a way that it will keep growing its memory usage on need (Exception large pages) and will not scale down its usage unless there is low memory notification from Windows. We can control the memory usage of SQL Server using Max server memory setting in SQLServer. This setting limits the Bpool usage of SQL Server and doesn’t control the overall memory usage of SQLServer. There are portions of SQLServer memory that is allocated outside BPOOL (aks: MTL or MTR) we do not have a way to control how much memory SQL Server can use outside bpool, but non bool memory usage will be normally low and can be easily estimated by studying the components running in SQL Server.

Ex: If you want to set SQLServer to use only 10GB RAM on server. Consider how much memory SQL Server might need outside Bpool and set the “max server memory” setting accordingly. In this case if you estimate SQL Server will use 1.5GB outside Bpool then set the Max server memory to 8.5GB.

What can cause SQL Server Memory leak?

SQL Server code has a logic to allocate memory but doesn’t de-allocate it. If any of the components in SQL Server is causing a memory leak in SQL Server it can be identified easily using the DMV’s like sys.dm_os_memory_allocation,sys.dm_os_memory_clerks and sys.dm_os_memory_objects etc., but most of the memory leaks in SQL Server is caused by 3rd party Dll’s which are loaded in SQL Server process.

Note: All the memory allocations by Non SQL server Dll’s loaded in SQL Server will happens in “Mem to Leave”(outside the Bpool) and they are called as direct windows allocations (DWA)

When there is out of memory conditions in SQL Server and if you suspect there is a memory leak.First thing to determine is who is consuming the memory. If SQL Server is not using majority of the memory in MemToLeave and still you get Mem to leave errors probably there is a leak and it caused by some DLL’s loaded in

SQL Server. Refer Section 1 (MTL error) in https://mssqlwiki.com/sqlwiki/sql-performance/troubleshooting-sql-server-memory/

Below query can be used to determine actual memory consumption by SQL Server in MTL.

select sum(multi_pages_kb) from sys.dm_os_memory_clerks

If the memory consumption by SQL Server is very low and still if you see SQL Server memory errors like few below then focus on Leaks.

Ex:

SQL Server 2000

WARNING: Failed to reserve contiguous memory of Size= 65536.

WARNING: Clearing procedure cache to free contiguous memory.

Error: 17802 “Could not create server event thread.”

SQL Server could not spawn process_loginread thread.

SQL Server 2005/2008

Failed Virtual Allocate Bytes: FAIL_VIRTUAL_RESERVE 122880

How to identify and troubleshoot the memory leak?

There are multiple ways in windows to identify who is leaking memory in process. We will discuss how to identify the memory leak using

1. Windows debugger 2. Debug diagnostics tools for windows and 3. UMDH in this blog.

Let us create a sample DLL to load in SQL server process to leak memory and see how to use the tools I mentioned above to troubleshoot the leak.

Download HeapLeak.dll from This link and install Microsoft Visual C++ 2010 Redistributable Package from this links 32-Bit or 64-Bit to make this DLL work.

–Create an extended stored procedure in SQL Server

exec sp_addextendedproc  'HeapLeak','C:\HeapLeakdll\HeapLeak.dll'

–Let us execute this Extended SP 30 times and leak memory.

exec HeapLeak

go 30

We will also enable below trace flags in SQL Server to automatically generate filter dump when there is out of memory errors and see how to identify who is leaking.

dbcc traceon (2551,-1) — 2551 is used to enable filter dump.

dbcc traceon (8004,-1) –8004 is used to take memory dump on first occurrence of OOM condition

–Note: Both the trace flags listed above are un-documented, So use it at your own risk and there is no guarantee that this trace flags will work in future versions of SQL Server

Once we enable the trace flag . We have to cause out memory error in SQL Server to generate OOM memory dump. We have leaked around 300 MB of memory from MTL by executing above extended SP 30 times.

Let use execute below script which create XML handles. Memory for xml handles is allocated from MTL we will get out of memory errors very soon because extended stored procedure which we executed has already leaked the memory.

(Do not run below XML script directly with out executing HeapLeak Below script will cause OOM error because of handle created for each execution, but it is accounted as SQL Server allocation so will not help us to understand the how to debug leaks caused by 3rd party DLL’s)

Note: 1. SQL Server memory dump will be generated in SQL Server error log folder.
2. Size of MTL is 256 MB + Max worker threads *.5 in 32-Bit SQL Server. So approximately 384 MB unless modified using –g switch.

DECLARE @idoc int
 
DECLARE @doc varchar(1000)
 
SET @doc ='<ROOT>
<Customer CustomerID="VINET" ContactName="Paul Henriot">
<Order CustomerID="VINET" EmployeeID="5" OrderDate="1996-07-04T00:00:00">
     <OrderDetail OrderID="10248" ProductID="11" Quantity="12"/>
      <OrderDetail OrderID="10248" ProductID="42" Quantity="10"/>
   </Order>
</Customer>
<Customer CustomerID="LILAS" ContactName="Carlos Gonzlez">
   <Order CustomerID="LILAS" EmployeeID="3" OrderDate="1996-08-16T00:00:00">
   <OrderDetail OrderID="10283" ProductID="72" Quantity="3"/>
   </Order>           
</Customer>
</ROOT>'
 
EXEC sp_xml_preparedocument @idoc OUTPUT, @doc
 
go 10000

We will receive below error after few executions.

Msg 6624, Level 16, State 12, Procedure sp_xml_preparedocument, Line 1

XML document could not be created because server memory is low.

To analyze the dump download and Install Windows Debugger from http://msdl.microsoft.com/download/symbols/debuggers/dbg_x86_6.11.1.404.msi

Step 1 (Load the memory dump file to debugger):

Open Windbg . Choose File menu –> select Open crash dump –>Select the Dump file (SQLDump000#.mdmp)

Note : You will find SQLDump000#.mdmp in your SQL Server error log when you get the Exception or assertion.

Step 2 (Set the symbol path to Microsoft symbols server):

on command window type

.sympath srv*c:\Websymbols*http://msdl.microsoft.com/download/symbols;

Step 3 (Load the symbols from Microsoft symbols server):

Type .reload /f and hit enter. This will force debugger to immediately load all the symbols.

Step 4 (check if symbols are loaded):

Verify if symbols are loaded for SQL Server by using the debugger command lmvm

:028> lmvm sqlservr

start end module name

01000000 02ba8000 sqlservr (pdb symbols) c:\websymbols\sqlservr.pdb\93AACB610C614E1EBAB0FFB42031691D2\sqlservr.pdb

Loaded symbol image file: sqlservr.exe

Mapped memory image file: C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Binn\sqlservr.exe

Image path: C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Binn\sqlservr.exe

Image name: sqlservr.exe

Timestamp: Fri Oct 14 15:35:29 2005 (434F82E9)

CheckSum: 01B73B9B

ImageSize: 01BA8000

File version: 2005.90.1399.0

Product version: 9.0.1399.0

File flags: 0 (Mask 3F)

File OS: 40000 NT Base

File type: 1.0 App

File date: 00000000.00000000

Translations: 0409.04e4

CompanyName: Microsoft Corporation

ProductName: Microsoft SQL Server

InternalName: SQLSERVR

OriginalFilename: SQLSERVR.EXE

ProductVersion: 9.00.1399.06

FileVersion: 2005.090.1399.00

FileDescription: SQL Server Windows NT

LegalTrademarks: Microsoft® is a registered trademark of Microsoft Corporation. Windows(TM) is a trademark of Microsoft Corporation

Comments: NT INTEL X86

Step 5 : (!address to display the memory information)

Use !address command to display the memory information of the process from dump.

0:028> !address -summary

——————– Usage SUMMARY ————————–

TotSize ( KB) Pct(Tots) Pct(Busy) Usage

686a7000 ( 1710748) : 81.58% 81.80% : RegionUsageIsVAD

579000 ( 5604) : 00.27% 00.00% : RegionUsageFree

4239000 ( 67812) : 03.23% 03.24% : RegionUsageImage

ea6000 ( 15000) : 00.72% 00.72% : RegionUsageStack

1e000 ( 120) : 00.01% 00.01% : RegionUsageTeb

122d0000 ( 297792) : 14.20% 14.24% : RegionUsageHeap

0 ( 0) : 00.00% 00.00% : RegionUsagePageHeap

1000 ( 4) : 00.00% 00.00% : RegionUsagePeb

1000 ( 4) : 00.00% 00.00% : RegionUsageProcessParametrs

1000 ( 4) : 00.00% 00.00% : RegionUsageEnvironmentBlock

Tot: 7fff0000 (2097088 KB) Busy: 7fa77000 (2091484 KB)

——————– Type SUMMARY ————————–

TotSize ( KB) Pct(Tots) Usage

579000 ( 5604) : 00.27% : <free>

4239000 ( 67812) : 03.23% : MEM_IMAGE

5fc000 ( 6128) : 00.29% : MEM_MAPPED

7b242000 ( 2017544) : 96.21% : MEM_PRIVATE

——————– State SUMMARY ————————–

TotSize ( KB) Pct(Tots) Usage

1b7bd000 ( 450292) : 21.47% : MEM_COMMIT

579000 ( 5604) : 00.27% : MEM_FREE

642ba000 ( 1641192) : 78.26% : MEM_RESERVE

Largest free region: Base 00000000 – Size 00010000 (64 KB)

Look at the RegionUsageHeap it is around 297792 KB and largest free region is just 64KB. We know SQL Server doesn’t use Heap’s extensively so normally the heap allocated by SQL Server will not go beyond few MB. In this case it is consuming around 290 MB and so other components which use MTL can easily fail.

Let us try to understand why the Heap is around 297792 KB and try to identify if there is a pattern.

Step 6: (Let us use !heap –s to display summary information about the heap)

0:028> !heap -s

LFH Key : 0x672ddb11

Heap Flags Reserv Commit Virt Free List UCR Virt Lock Fast

(k) (k) (k) (k) length blocks cont. heap

—————————————————————————–

000d0000 00000002 1024 896 896 6 1 1 0 0 L

001d0000 00008000 64 12 12 10 1 1 0 0

002c0000 00001002 1088 96 96 2 1 1 0 0 L

002e0000 00001002 64 52 52 3 2 1 0 0 L

007c0000 00001002 64 64 64 56 1 0 0 0 L

00d10000 00001002 256 24 24 8 1 1 0 0 L

340b0000 00001002 64 28 28 1 0 1 0 0 L

340c0000 00041002 256 12 12 4 1 1 0 0 L

342a0000 00000002 1024 24 24 3 1 1 0 0 L

34440000 00001002 64 48 48 40 2 1 0 0 L

61cd0000 00011002 256 12 12 4 1 1 0 0 L

61d10000 00001002 64 16 16 7 1 1 0 0 L

61d20000 00001002 64 12 12 4 1 1 0 0 L

62a90000 00001002 1024 1024 1024 1016 2 0 0 0 L

62b90000 00001002 1024 1024 1024 1016 2 0 0 0 L

62c90000 00001002 256 40 40 7 1 1 0 0 LFH

00770000 00001002 64 16 16 2 2 1 0 0 L

63820000 00001002 64 24 24 3 1 1 0 0 L

63830000 00001001 10240 10240 10240 160 21 0 0 bad

64230000 00001001 10240 10240 10240 160 21 0 0 bad

64c30000 00001001 10240 10240 10240 160 21 0 0 bad

65630000 00001001 10240 10240 10240 160 21 0 0 bad

66030000 00001001 10240 10240 10240 160 21 0 0 bad

66a30000 00001001 10240 10240 10240 160 21 0 0 bad

67430000 00001001 10240 10240 10240 160 21 0 0 bad

68130000 00001001 10240 10240 10240 160 21 0 0 bad

68b30000 00001001 10240 10240 10240 160 21 0 0 bad

69530000 00001001 10240 10240 10240 160 21 0 0 bad

69f30000 00001001 10240 10240 10240 160 21 0 0 bad

6a930000 00001001 10240 10240 10240 160 21 0 0 bad

6b330000 00001001 10240 10240 10240 160 21 0 0 bad

6bd30000 00001001 10240 10240 10240 160 21 0 0 bad

6c730000 00001001 10240 10240 10240 160 21 0 0 bad

6d130000 00001001 10240 10240 10240 160 21 0 0 bad

6db30000 00001001 10240 10240 10240 160 21 0 0 bad

6e530000 00001001 10240 10240 10240 160 21 0 0 bad

6ef30000 00001001 10240 10240 10240 160 21 0 0 bad

6f930000 00001001 10240 10240 10240 160 21 0 0 bad

70330000 00001001 10240 10240 10240 160 21 0 0 bad

70d30000 00001001 10240 10240 10240 160 21 0 0 bad

7a160000 00001001 10240 10240 10240 160 21 0 0 bad

7ab60000 00001001 10240 10240 10240 160 21 0 0 bad

7b560000 00001001 10240 10240 10240 160 21 0 0 bad

7d0d0000 00001001 10240 10240 10240 160 21 0 0 bad

7e030000 00001001 10240 10240 10240 160 21 0 0 bad

7ea30000 00001001 10240 10240 10240 160 21 0 0 bad

67f90000 00001003 256 16 16 14 1 1 0 bad

71850000 00001003 256 4 4 2 1 1 0 bad

71890000 00001003 256 4 4 2 1 1 0 bad

67fd0000 00001002 64 16 16 4 1 1 0 0 L

718d0000 00001003 256 40 40 3 1 1 0 bad

71910000 00001003 256 4 4 2 1 1 0 bad

71950000 00001003 256 4 4 2 1 1 0 bad

71990000 00001003 256 4 4 2 1 1 0 bad

67ff0000 00001002 64 16 16 4 1 1 0 0 L

719d0000 00001003 1792 1352 1352 5 2 1 0 bad

71a10000 00001003 256 4 4 2 1 1 0 bad

71a50000 00001003 256 4 4 2 1 1 0 bad

71a90000 00001002 64 16 16 1 0 1 0 0 L

—————————————————————————–

If you look at the above out put you can clearly identify a pattern. There are multiple created and each of them is 10 MB. But how to identify who actually created them?

Step 7:

Let us pickup one of the heap which is 10 MB and display all the entries (allocations) with in this 10 MB heap using !heap with –h parameter

Heap I have picked is 63830000.

0:028> !heap -h 63830000

Index Address Name Debugging options enabled

19: 63830000

Segment at 63830000 to 64230000 (00a00000 bytes committed)

Flags: 00001001

ForceFlags: 00000001

Granularity: 8 bytes

Segment Reserve: 00100000

Segment Commit: 00002000

DeCommit Block Thres: 00000200

DeCommit Total Thres: 00002000

Total Free Size: 00005048

Max. Allocation Size: 7ffdefff

Lock Variable at: 00000000

Next TagIndex: 0000

Maximum TagIndex: 0000

Tag Entries: 00000000

PsuedoTag Entries: 00000000

Virtual Alloc List: 63830050

UCR FreeList: 63830588

FreeList Usage: 00000000 00000000 00000000 00000000

FreeList[ 00 ] at 63830178: 6422de88 . 638ad7e0 Unable to read nt!_HEAP_FREE_ENTRY structure at 638ad7e0

(1 block )

Heap entries for Segment00 in Heap 63830000

63830608: 00608 . 00040 [01] – busy (40)

63830648: 00040 . 02808 [01] – busy (2800)

641b6698: 02808 . 02808 [01] – busy (2800)

……………………………………

Step 8: (Let us pickup one of the heap entry (allocation) and try to identify what is in it)

0:028> db 641b6698

641b6698 01 05 01 05 93 01 08 00-49 61 6d 20 66 69 6c 69 ……..Iam fili

641b66a8 6e 67 20 74 68 65 20 68-65 61 70 20 66 6f 72 20 ng the heap for

641b66b8 64 65 6d 6f 20 61 74 20-4d 53 53 51 4c 57 49 4b demo at MSSQLWIK

641b66c8 49 2e 43 4f 4d 00 00 00-00 00 00 00 00 00 00 00 I.COM………..

641b66d8 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …………….

641b66e8 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …………….

641b66f8 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …………….

641b6708 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …………….

0:028> db 63830648

63830648 01 05 08 00 89 01 08 00-49 61 6d 20 66 69 6c 69 ……..Iam fili

63830658 6e 67 20 74 68 65 20 68-65 61 70 20 66 6f 72 20 ng the heap for

63830668 64 65 6d 6f 20 61 74 20-4d 53 53 51 4c 57 49 4b demo at MSSQLWIK

63830678 49 2e 43 4f 4d 00 00 00-00 00 00 00 00 00 00 00 I.COM………..

63830688 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …………….

63830698 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …………….

638306a8 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …………….

638306b8 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …………….

Similarly you can dump multiple heap allocations to identify a pattern.

Now if you look at the memory dumped you see a string which might help you to identify the DLL which created the heap. There is a pattern in above heaps. All the heap allocations have below string

“Iam filing the heap for demo at MSSQLWIKI.COM”

Note : You can use L Size to dump more memory using db or dc command’s example db 63830648 L1500

Step 9:

Let us open the DLL which we loaded in SQL Server for testing using notepad and see if there is string which matches the pattern

Yes there is which proves that this DLL’s has caused the leak. In real time you may have to play with different heap allocations to identify the pattern.

This is one way to find the leaks from the memory dump after the leak has actually happened. It may not be always easy to find a pattern and identify the modules who allocated the memory, In such scenarios you may have to track the leak using the tools like debug diagnostic tool, UMDH etc.In the my next blog I will post how to track memory leak using Debug diagnostics tool.

Continued in Debugging memory Leaks using Debug diagnostic tool

SQL Server 2012 Memory

Troubleshooting SQL Server Memory

A significant part of SQL Server process memory has been paged out

Thank you,

Karthick P.K |My Facebook Page |My Site| Blog space| Twitter

Posted in Debugging, Memory, Performance, SQL General, SQL Server Engine | Tagged: memory leak, Memory leaks in SQL Server, MTL erros in SQL Server, sqlserver memory, tracking memory leaks in SQL Server | 42 Comments »

MSSQLWIKI

Karthick P.K on SQL Server

Karthick P.K

Categories

Archives

Tags

Facebook

Twitter

Do you have a question in SQL Server or stuck in SQL Server issue? Click here to join our facebook group and post your questions to SQL Server experts

Email Subscription

SQLWiki

Subscribe

feedburner email subscription

Visits

SQL Server Blogs

Author

Other SQL blogs

SQLSERVERSCRIBBLES.COM

Posts Tagged ‘memory leak’

Debugging memory Leaks using Debug diagnostic tool.

SQL Server memory leak

MSSQLWIKI

Karthick P.K on SQL Server

Karthick P.K

Categories

Archives

Tags

Facebook

Twitter

Do you have a question in SQL Server or stuck in SQL Server issue? Click here to join our facebook group and post your questions to SQL Server experts

Email Subscription

SQLWiki

Subscribe

feedburner email subscription

Visits

SQL Server Blogs

Author

Other SQL blogs

SQLSERVERSCRIBBLES.COM

Posts Tagged ‘memory leak’

Debugging memory Leaks using Debug diagnostic tool.

Share this:

Like this:

SQL Server memory leak

Share this:

Like this: