This article has been contributed by Ryan Doon, a PFE working with Microsoft Canada. In this post, he talks about why storing PST files on a file server will lead to performance issues, and presents some options to proactively avoid those issues.
As a Premier Field Engineer at Microsoft I am always looking to determine how to optimize an environment. Whether this environment is a single computer, or many servers, there are always some best practices that can assist in optimizing your environment for performance and reliability.
The optimal location to store a PST is quite a hot topic. The Windows Server Performance Team created a very detailed blog post about this topic. In this blog post, I have attempted to simplify the message for easier understanding and I also detail possible options that you have for avoiding those issues.
PST files were created to allow users to maintain a copy of their messages on their local computers. The PST files also serve as a message store for users who do not have access to a Microsoft Exchange Server computer (for example POP3 or IMAP email users). PST files were never designed to be a network based solution. It is possible to specify a network location for PST files, but this usage is not meant to be a long term and continuous use solution.
PST Files are accessed by a method called file-access-driven, which means that this method utilizes special file access commands which will be offered by the OS to read and write files. For writing files to local disks this is an excellent method, but when writing to a fileserver via a LAN/WAN another method should be used. This method is called network-access driven and uses specific commands from the OS to send/receive data from/to other systems which are connected to the network
Since the PST file is a file-access-driven method of message storage it is efficient to store the PST locally, and not efficient on WAN or LAN links because WAN and LAN links use network-access driven methods. If there is a remote PST file (over a network link), Outlook tries to use the file commands to read from the file or write to the file. However, the operating system must then send those commands over the network because the file is not located on the local computer. This creates lots of overhead and increases the time that is required to read and write to the file.
Firstly, the use of a PST file over a network connection may result in a corrupted PST file if the connection degrades or fails, and writing to a PST can take 4 times longer than read actions.
Many users who host PST files on a file server might have issues with system hangs or resource depletion. System hangs are often seen during times that outlook and the PST files are heavily used. This is often seen in the morning when users are logging on and launching outlook. As mentioned above, placing PST files on the network creates a lot of overhead for the system due to PST files being file-access-driven and not network-access-driven. Multiple users using the PST files create a request of many Gigabytes of data being requested at the same time. These requests require a lot of Disk & Network I/O to be processed simultaneously. The file server “freezing” is a very common scenario during the time it tries to service all the requests.
The queuing in the server service work queues is what causes this temporary hang. The server service uses work items to handle I/O requests that come in over the network - for example: a request to extend a PST file. These work items are queued in the server service work queues, and from there they are handled by the server service worker threads. The work items are allocated from a kernel resource called Non-Paged Pool (NPP).
The server service sends these I/O requests down to the disk subsystem. If, for reasons mentioned above, the disk subsystem does not respond in time due to heavy requests, the incoming I/O requests are queued via work items in the server work queues. Since these work items are allocated from NPP, eventually this resource runs empty. Running out of NPP causes systems to hang eventually.
Many times on file servers hosting PST files you will see SRV errors in the event logs. This problem occurs because the Server service cannot keep up with the demand for network work items that are queued by the network layer of the I/O stream. The Server service cannot process the requested network I/O items quickly enough to the hard disk and exhausts available resources, which leads to system hangs.
From an Exchange Server perspective the practice of PST files stored anywhere pose several issues in addition to those listed above:
While there are several options to addressing the issue of what to do with all the PST data, each can bring with it a different set of challenges.
While this may be the easiest and least expensive to implement it possess the most risk in terms of data loss and protection.
1 Please note that this is a third party product and is mentioned here as-is for illustration purposes. Microsoft does not endorse or recommend a specific third party product.
To ensure file server health, PST files should never be hosted on a file server. There is no question if hosting the PST files on the file server will cause an issue, the question is just a matter of when the issue will occur.
We have also presented some server side options which allow easier management of mails. Using the information presented in this article you can make the right decision on which method of managing the mailbox content works best for your setup.
Posted by Arvind Shyamsundar, MSPFE Editor.
I think the Ask Perf team also wrote something about network-stored PST a little while ago.
did you have a chance to test new server 2012 scale-out files shares for storing pst files? if yes, what is the verdict?
I am having an issue with my .pst file disappearing from Outlook after I exit the program and open it again. So whenever I open Outlook I have to open the .pst or add it again from the account settings window. The .pst file is located on a network hard drive that is backed up everyday, not locally on my workstation.
I was wondering if this is something you have seen before and if saving the data file locally would prevent it from disappearing.