ネットワーク上の PST (OST) 【後編】なぜパフォーマンス低下が発生するか


こんにちは。日本マイクロソフト Outlook サポート チームです。

Outlook のデータ ファイルへネットワーク越しにアクセスすることで発生する問題についてご紹介する記事の後編です。

前回の記事ではネットワーク越しに PST や OST へアクセスを行う構成では様々な問題が発生するため、一部のシナリオを除いてサポート対象外であることをご紹介しました。今回は、そうした問題の中で、パフォーマンスの悪化がなぜ発生するかに焦点を絞って説明します。

まず、パフォーマンスの悪化は基本的に PST や OST を配置したファイル サーバーとネットワーク上で発生します。Outlook は、「データ ファイルがローカルに存在しスムーズにアクセスできる」という想定で開発されているため、上述のようなファイル サーバーやネットワーク上の遅延により PST や OST へのアクセスに待ちが発生すると応答なしになるなどの影響を受けるようになります。

また、この時問題となるのはネットワーク帯域ではなく、アクセスの遅延となります。Outlook は PST や OST に対して、通常 512 バイトから 8K バイト程度の単位でのランダム アクセスを行います。ランダム アクセスとは、インデックスを使用してデータの位置を特定して必要な個所だけにアクセスする方法となっており、処理に必要な時間の短縮が期待されます。しかしながら、Outlook からデータ ファイルへのアクセス回数が極めて多くなるため、ネットワークやファイル サーバーで発生した一度の遅延で待ちに回される処理が結果として多くなり、累積により更に大きな遅延につながります。

また、パフォーマンス悪化が発生するシナリオの詳細な説明としては、英語の内容になりますが以下のマイクロソフト Technet ブログで紹介されています。

Title : Network Stored PST files … don’t do it!
URL : <https://blogs.technet.microsoft.com/askperf/2007/01/21/network-stored-pst-files-dont-do-it/>

その内容を日本語で要約してみました(青字部分)。
読みやすいように原文から構成や内容を一部変更していますので容赦ください。

PST のファイル サイズが増える際の処理
例えば、あるユーザーが社内の 500 ユーザーへメールを送信したとします。すべてのユーザーの受信メールがファイル サーバー上の PST に格納される環境と仮定しましょう。

これらの受信者のうち一部の環境では、受信メールを格納するために PST のファイル領域の拡大が必要になるでしょう。PST のファイル領域を拡大するには、ディスク上で NTFS による追加の領域割り当てが発生します。この処理を行う際、使用可能な領域の割り当てが完了してマスター ファイル テーブル (MFT) が更新されるまでの間、ボリュームがロックされます。こうした処理が各ユーザーについて発生する間、他のユーザーにおけるディスクの読み取り、書き込みの処理が保留されます。また、ディスクが断片化された環境ではフリーの領域の割り当てに更なる時間を必要とします。
 
以上のように、複数のユーザーの PST が同時にファイル領域の拡大を行おうとすることで、幾度もの MFT のロックアウトが検知され、ボリューム上の他のいかなるファイルにもアクセスできない状況が発生します。その結果としてサーバー サービスのキューに待ち行列が発生し、ソース : srv のイベント ID 2019、2020、2021、2022 がイベント ログに記録され、ファイル サーバーおよびファイル サーバー上のデータ ファイルを参照している Outlook のパフォーマンス低下が発生します。

Outlook 起動時に行われる処理
次に、数百人のユーザーが、一人当たり 2 つや 3 つの PST ファイルを持っているシナリオについて考えてみましょう。
これらのユーザーが外出が多く、滅多に (一度も) PST から不要なメールの削除を行わないということはあり得るでしょう。
その場合、PST は肥大化を続けますが、ここでは、平均して 1 GB の PST がそれぞれのユーザー環境に存在すると想定します。
 
こうした状態でそれぞれのユーザーが Outlook を起動した場合、Outlook は 2 つ (もしくは 3 つ) のファイルにリクエストを行いますが、それぞれのファイルが 1 GB のサイズとなっています。
ユーザーが 200 人いて、始業時間に一斉に Outlook を起動した場合、200 x 3 x 1 = 600 GB のデータが同時にリクエストされることになります。
これはディスクとネットワークにとって I/O を一度に処理するには多すぎるデータ量となります。
このような場合に、結果としてこれらのデータを処理するためにファイル サーバーが数分に渡って応答なしの状態になります。

まとめ
以上のように、サーバー サービスのキューの待ち行列が一時的なハングを生み出します。
ネットワーク経由で入ってくる、例えば PST ファイル領域の拡張などの I/O リクエストをサーバー サービスはワーク アイテムを使用して処理をハンドルしていきますが、これらのワーク アイテムは非ページプール (Non-Paged Pool,NPP) と呼ばれるカーネル リソースにより行われます。
 
サーバー サービスはこれらの I/O 要求をディスク サブシステムに改めて要求します。ここで、これまでに述べたような理由からディスク サブシステムが許容される時間内に応答できないため、サーバー処理のキューにワーク アイテム経由で入ってくる I/O 要求は処理待ちの状態で溜まっていきます。 これらのワーク アイテムは非ページプールによって配分されるため、このリソースがやがて枯渇する状況が発生します。 非ページプールの枯渇はやがてシステムのハングにつながります (この時、プロセスにイベント ID 2019 が記録されます) 。

以上が英語記事の要約です。

少し長くなってしまいましたが、とても良い記事でしたのでこちらでもご紹介しました。

また、これは原文では触れられていませんが、このブログ記事の前編でも紹介しているように、最悪の場合は非ページプールの枯渇によりストップ エラーが発生し、サーバーがダウンするという深刻な問題が発生する場合がありますので、ネットワーク越しの PST や OST へのアクセスが推奨されないという点について、改めてご留意ください。

本情報の内容 (添付文書、リンク先などを含む) は、作成日時点でのものであり、予告なく変更される場合があります。

Skip to main content