Windows Server 2008 - Memory Leak - SMB2

Published on
10,249 Points
1 Endorsement
Last Modified:
 It would seem that when you are copying files between two Windows 2008 x64 servers it first copies the file into memory before sending the file to it’s destination.  The larger the file you try to copy the more memory it will consume and the more it will increase the likelihood of us running out of memory. This problem does not manifest when files are copied between different Windows Server versions (2003 to 2008). I’ll include a technical explanation below.

  To protect us going forward we are implementing a moratorium on copying large files through Windows Explorer from any Windows 2008 servers  when the destination OS is any of the following: Vista (any version), Windows 7 (any version), and Windows 2008.

Technical Explanation

Attached, find an image from some perfmon counters running on Primary Database server during the problem period that shows the Cache Bytes increasing (file copy consuming available memory) and the Available Memory Bytes decreasing.
 Test Resulted in Large Memory Consumption

Large file copy within Windows Explorer between 2 Windows 2008 Servers (The OS decides to use SMB2)
Test Resulted in No Memory Consumption Problems

 Large file copy within Windows Explorer between 1 Windows 2003 Server and 1 Windows 2008 Server

Large file copy within Windows Explorer between 2 Windows 2008 Servers with SMB2 disabled

Large file copy between 2 Windows 2008 Servers using ESEUTIL to copy the file
  According to Microsoft the Windows Explorer is performing as designed when executing a copy of a large file. When Windows Server determines that it has 2, Windows 2008 servers communicating, it uses SMB2 to facilitate the transfer, which leverages a buffered file copy. There are many utilities that suffer from this problem as well (OS commands COPY, XCOPY, and ROBOCOPY (2008 only)).
  The only safe work around when moving files between 2 Windows 2008 Servers is to use an Exchange utility called ESEUTIL. One of the methods this utility supports is what’s called an unbuffered copy, ie 0 impact on available memory’s bottom line.

Author Comment

We came across this issue because it crippled our SQL Servers in production. A large file was being transferred (a database Backup) from one SQL Server to another. This had massive impact upon the available memory for the the SQL Server process.
LVL 51

Expert Comment

by:Ted Bouskill
Ah, you should have mentioned that specific example.

Have you set any limits to the memory SQL is allowed to use?  Sadly SQL server will try to consume all physical memory and doesn't care if swapping starts to occur (which will kill performance)

What method are you using to do the file copy?  Is it a batch file or did you setup an SSIS automated task to execute the copy?
LVL 15

Expert Comment

by:Eric AKA Netminder

Congratulations! Your article has been published.

Page Editor

Expert Comment

by:Bradley Vonderheide
Pretty sure if you turn off superfetch in the system services it fixes this issue as well..

Featured Post

Introducing Cloud Class® training courses

Tech changes fast. You can learn faster. That’s why we’re bringing professional training courses to Experts Exchange. With a subscription, you can access all the Cloud Class® courses to expand your education, prep for certifications, and get top-notch instructions.

Join & Write a Comment

This tutorial will walk an individual through locating and launching the BEUtility application and how to execute it on the appropriate database. Log onto the server running the Backup Exec database. In a larger environment, this would generally be …
This tutorial will walk an individual through the steps necessary to configure their installation of BackupExec 2012 to use network shared disk space. Verify that the path to the shared storage is valid and that data can be written to that location:…

Keep in touch with Experts Exchange

Tech news and trends delivered to your inbox every month