Network上になぜOutlookの個人用フォルダファイルを置いてはいけないか

Network Stored PST files ... don't do it!

週に1度はパフォーマンスチームの誰かが顧客のファイルサーバーのハングやリソース不足についての相談を受けます。そのファイルサーバーはユーザーのファイルの保存場所で、ユーザーはこのサーバーに保存されているOutlookの個人用フォルダファイル(.pst)にClient PCからアクセスしています。この問題はサーバーのハングか、ページプールの減少(Event ID 2020)として現れます。たいていはこの問題は朝一で、起こります。ユーザーがPCにログインしてOutlookを開始したときです。特にひどい場合は毎日何度も起こります。時にはサーバーは数分ハングし、また数分動作し、またハングします。繰り返し繰り返し。ユーザーは自分のファイルアクセスが遅いことにいらいらし、サーバー管理者はこの問題を解決しなければならないことにいらいらし、その上司はみんながいらいらしていることにいらいらします。

もしあなたがこのじょうきょうにいるのであれば、いい知らせと、とても悪い知らせがあります。いい知らせは、この問題はとてもよくあるタイプの既知の問題であること。とても悪い知らせは、(顧客の立場からですが、)LANやWAN上のPSTファイルはサポートされている状況ではないことです。顧客によってはこれを知ってとても驚くのですが、ネットワーク上に保存されたPSTファイルはExchange 4.0の頃からサポートされていません。MicrosoftのKB297019はネットワーク上のPSTファイルの影響について案内しています。

「.pst ファイルは、ユーザーがローカル コンピュータ上にメッセージのコピーを保持できるように、Microsoft Exchange Server 4.0 チームにより作成されました。また、この .pst ファイルは、Microsoft Exchange Server コンピュータへのアクセス権のないユーザー (たとえば、Microsoft Outlook のインターネット メールのみ (IMO) モードのユーザー) のメッセージ ストアとしても使用されます。 」

「一方、WAN または LAN リンクでは、他のネットワーク コンピュータとの間のデータ送受信のためにオペレーティング システムが提供するコマンドが使用されるため、.pst ファイルの使用は効率的ではありません。リモート .pst がネットワーク リンク上に存在する場合、Microsoft Outlook はファイル アクセス用のコマンドを使用してファイルに対する読み書きを行いますが、.pst ファイルがローカル コンピュータに存在しないため、オペレーティング システムがこれらのコマンドをネットワーク経由で送信する必要があります。これにより大きなオーバーヘッドが生じ、ファイルの読み書きに要する時間が増大します。また、ネットワーク接続上で .pst ファイルを使用すると、接続の状態が悪化したり接続が中断したりした場合に .pst ファイルが破損するおそれもあります。 」

ひとつの例を使用してこの問題の詳細と結果について見てみましょう。

たとえばユーザーが社内500人にメールを送ったとしましょう。すべてのユーザーがファイルシェアに保存されたPSTファイルに直接メールを保存しているとします。そのうちの何人かは、この目0るを受け取るためにPSTファイルを拡張しなければならないかもしれません。拡張するためには、NTFSを通じてディスクに追加割り当てをしなければなりません。空き容量が割り当てられる間この動作がディスクのボリューム全体をロックアウトし、MFT (Master File Table)を更新します。これが各ユーザーに行われている間、残り500人の読み書きは待ち状態になります。

空き領域の割り当ては時間をとる場合があります。ディスクが断片化している場合には特に時間がかかります。複数のユーザーが同時にそれぞれのPSTの拡張を行った場合、顕著な期間のMFTロックアウトが見られる場合があります。この場合、ユーザーはその間このボリュームの中のどんなファイルにもアクセスできず、結果サーバーのキューがたまり、時にはSRV 2019, 2020, 2021, 2022といったようなイベントが記録されます。この場合、ディスクには大きな負荷がかかります。

ひとつのメールが複数人に送られるこの例はさておき、あなたがPSTファイルを2-3個持ったユーザーを数百人持っているとします。ユーザーはしばらくの期間会社に在籍し、その期間メールをほとんど、もしくはまったくPSTファイルから削除しません。ファイルはどんどん大きくなり、平均1GBだったとします。ユーザーがOutlookを起動し、2-3個のPSTファイルにアクセスし、それぞれが1GBだったら。始業時に200人がいっぺんにOutlookを立ち上げたらどうなるでしょう。ディスクやネットワークがひどい状況になります。こういったリクエストにサーバーが答えるために数分フリーズする、これがこの場合のよくあるシナリオです。

サーバーに処理町のキューがたまる状況が一時的なハングを起こします。サーバーサービスはこういったネットワーク越しの入出力リクエストを処理するために使用されます。たとえば、PSTファイルを拡張するリクエストなど。これらの処理はサーバーサービスのキューにたまり、ここから一連で処理されます。こういった処理は非ページプール(NPP)と呼ばれるか寝るリソースから割り当てられます。

サーバーサービスはこういった入出力リクエストをディスクサブシステムに送ります。もし上で紹介した理由でディスクサブシステムがなかなか応答しなかった場合、入ってくる入出力リクエストはサーバーのキューにたまります。こういったものがNPPから割り当てられているためリソースは不足します。NPPリソース不足はハングを起こします。(そしてEvent ID 2019を記録します。)

この問題をトラブルシューティングの観点から掘り下げると、PSTファイルによって引き起こされたトラブルは通常明白にPoolmonとPerfmonのキャプチャに見ることができます。たとえば、LSwnプールタグ割り当てがPoolmonの中で上昇するのが見えるかもしれません。これらの割り当てはSRV.SYSにより行われます。割り当てサイズはSizReqBufレジストリで設定できます。サーバーサービスに使用される各work itemに割り当ては使用されます。これをPerfmonを通してみると、"利用可能なWork Item"カウンターの減少に気がつくでしょう。もし利用可能なWork Itemが0になれば、Client PCはPSTだけではなくどんなファイルにもアクセスできなくなるかもしれません。また、問題がLSwnの割り当て(非ページプールの減少)にあれば、2019エラーを見るかもしれません。

MmStタグもPSTファイルの問題を明確にします。このタグはMm Section object prootypePTE - マップファイルとして使用されるメモリ管理関連のシステムをあらわします。別の観点から言えば、これは共有ファイルを管理するのに私用されるOSメモリをマップする際に使用されるプールタグです。MmStの問題は時々ページプールの減少としてあらわれます。

こういった影響を和らげるために行うことのできるサーバー側の調整はあるでしょうか。あります。それがこの問題を完全に解決する保障はあるでしょうか。ありません。環境が大きくなるに従い、管理者サイドでできる調整にもかかわらずこの問題は続くでしょう。いつか、調整自体が問題を大きくしかねません。純粋にサーバーが処理しきれなくなるからです。