Skype for Business and Lync 2013 Memory Usage


Skype for Business and Lync 2013 clients manage memory differently than previous client versions. This article describes the design change, how it impacts client performance, and how it affects the memory footprint. For purposes of this article, the term “Lync 2013” relates to Lync 2013 and Skype   Business clients. At the time of this writing, the executable name for Lync 2010, 2013 and Skype for Business clients is lync.exe.

Author: Steve Schiemann

Product Versions: Lync 2010, 2013/Skype for Business 2013

Design Changes

At a high level, the difference between Lync 2013 and Lync 2010 memory usage patterns stem from two main changes. Each change will be discussed in more detail below.

  1. Lync 2013 does not proactively flush working set memory
  2. Lync 2013 uses shared office components

Working Set Trimming

Lync 2013 relies more on the operating system to manage memory compared to Lync 2010. This allows the lync.exe process to effectively utilize physical memory when available and at the same time allowing the operating system (OS) to trim lync.exe’s working set when other application demand more. By allowing the OS to manage physical memory, Lync 2013 can reduce the number of page faults thereby improving the overall system performance.

Lync 2010 performs explicit flushing of the working set memory when the main window of the application is minimized or closed to run in system tray even when physical memory is already available for use by other applications. This explicit flushing of the working set consumes operating system resources, and causes page faults when the Lync application demands more physical memory from the paging file. This impact can be observed by measuring the number of page faults when Lync client is minimized/running in system tray and executing core scenarios like receiving IM, receiving P2P audio call or joining a meeting. In real time communication scenarios, this impact can translate to delays in effective use of the application.

Page faults occur when there is not enough physical memory on the machine to meet memory demands. When this occurs, memory is copied from physical RAM to a swap file on the hard disk drive, and then make room to enable the requested memory allocation to complete. This is a very expensive operation because this swap requires a series of reads and writes on the hard disk drive, and this process must be completed before the operation that caused the fault can resume.

In Lync 2013, if the OS needs the memory for other programs, lync.exe’s working set will still get trimmed, but only when needed. This design change improves the overall performance of Lync 2013, and the host machine as well.

The graph below is a sampling of the page faults for 2010 and 2013 collected on the same machine, running the same Lync account while executing the same set of scenarios in the same sequence.

As you can see there is a significant decrease in the number of page faults for Lync 2013\Skype for Business:

 

MM1

The graphs below show Page Faults/sec and Working set memory while executing the above scenarios.

Shared Office Components

Lync 2013 is more strongly integrated with other office components and shares several office components and resources. This move effectively allows Lync 2013 client to provide a much richer user interface (UI) experience compared to Lync 2010. Reusing office components has also increased the working set of Lync 2013 compared to Lync 2010. This increase in working set can be attributed to advanced caching strategies, use of hardware vs software rendering when appropriate, animations and fluidity of the user experience (UX).

In addition to richer UX, sharing office components allows Lync 2013 to share working set with other office applications running on the same machine consuming the shared components. This can be observed by capturing a virtual memory snapshot of Lync process and another office application (Outlook -2013) running on the same machine and components like msod.dll loaded into memory (working set) is being shared by both the applications.

With Lync 2013 being part of office suite of applications, many users have Lync & other Office applications (Outlook, OneNote) running on the same box. This combination results in a much more effective usage of working memory set even though the working memory size is bigger when viewed individually from Lync 2013 as a standalone application. Lync 2010 running on the same box as other Office applications does not share Office components in memory, effective resulting in less effective usage of working memory set across applications.

Implications of These Changes

You might notice that the Lync 2013 client may use a significant amount of memory, depending on how long it has been running, and what activities have been performed with the client. When looking at a graph of Private Byes, Virtual Bytes, and Working Set in Performance Monitor, you might see a constant increase in these counters for lync.exe, especially during the working day. These counters will typically not decrease overnight if lync.exe is left running.

For some applications that trim their own working set, this could be a sign of a memory leak. However, because of the design changes mentioned above, chances are good that this is NOT a leak. The real question to ask is whether there any actual performance problems associated with this level of memory consumption, with this application, other applications, or the operating System? If real performance problems are seen, further investigation would be warranted.

Resources

Working Set
https://msdn.microsoft.com/en-us/library/windows/desktop/cc441804(v=vs.85).aspx

Ask the Performance Team – PRF: Memory Management (Working Set Trimming)
http://blogs.technet.com/b/askperf/archive/2009/04/10/prf-memory-management-working-set-trimming.aspx

Working Set Trimming can negatively impact SQL, Exchange, and Operating System performance under Windows 2003
https://support.microsoft.com/en-us/kb/2001745

Excessive paging on Exchange 2007 servers when working sets are trimmed
http://blogs.technet.com/b/mikelag/archive/2007/12/19/working-set-trimming.aspx

 

Comments (6)

  1. Alejandro Araujo Rajzner says:

    Very nice article Steve. I thought NextHop was deprecated for the Office 365 blog, but I can see is alive and with nice articles again. Please keep them coming!

  2. Hi Guys,

    Great article. 🙂

    Would you be able to do a post on the Unified contact store? how it works? and the advantages?

    Thanks,
    Daniel

    1. Kris-MSFT says:

      Hi Daniel, we’ll see if we can get something together on this. Thanks for the suggestion!

  3. W07 says:

    Great Article Steve,
    Does this have any bearing on the server side also. I’ve noticed for a while that the performance counters on especially Fe Primary registrars are continuously increasing until after a scheduled reboot. There are however no associated performance issues seen yet. But I’m curious to know if these two are related.

    1. Steve says:

      Hi W07, there is no correlation between the client design changes mentioned in this post and resource usage on FE servers. The key thing to note, is if there are actual performance problems associated with these un-named perf counters you mention, and you say not so. If you need more information on the perf counters in question/why they are increasing, I suggest opening a support case. But there is no relation that I’m aware of.

  4. Ram Ojha says:

    I have noticed Lync 2013 \ SFB 2015 consuming lot of memory (and at times processor). This article neatly explains the reason. However, SFB 2016 is consuming significantly less resources than Lync 2013\SFB 2015. have things (perf related) changed in SFB 2016 compared to 2015?

Skip to main content