ファイル共有の仕組み - Server サービスと Workstation サービス -

Last Update: feedback 共有

本記事は 2014 年 6 月 1 日に公開された記事を本ブログに移行した記事になります。

こんにちは。Windows プラットフォーム サポート担当の加山です。

「ファイル サーバー上のファイルを開くのに時間がかかるようになった。」

ファイル サーバーを管理されているご担当者様などから、このような問題を解消したいといったお問い合わせをいただくことがあります。

今回はファイル サーバーを利用するにあたり、ファイル共有の仕組みを理解する上で基本となる 2 つのサービスについてお話します。

  1. Workstation サービス と Server サービス

Windows におけるファイル共有は「共有リソースへのアクセスを要求するクライアント (ワークステーション)」と「その要求を受け付けて処理を行うサーバー」で構成されており、それぞれ「Workstation
サービス」と「Server サービス」という名前のサービスがその役割を担っています。

次のようにサービスの一覧から 各サービスが起動していることを確認することができます。

Workstation サービス

Server サービス

  1. ファイル共有に必要なコンポーネント

Workstation サービスと Server サービスは、ネットワークのプロパティに表示されている「Microsoft ネットワーク用クライアント」と「Microsoft ネットワーク用ファイル共有とプリンタ共有」のコンポーネントに含まれており、ファイル共有を利用するには、この 2 つのコンポーネントが必要になります。

  1. ファイル共有へアクセスする流れ

では実際に、クライアントからサーバー上の共有フォルダーのリソースにアクセスする場合の処理の流れについてご説明します。

クライアント上では、アプリケーションがファイル共有を利用してリモートのファイルを要求すると、まず、Workstation サービスがその要求を受け付けます。これらの要求は、リダイレクター サブシステム (rdbss.sys) および SMB ミニリダイレクター (mrxsmb.sys) によって処理され、TCP/IP 経由の SMB プロトコル セッションおよび要求に変換されます。Windows Vista からは、SMB 2.0 プロトコルがサポートされており、mrxsmb10.sys ドライバーは従来の SMB トラフィックを処理し、mrxsmb20.sys ドライバーは SMB 2.x以降のトラフィックを処理します。

サーバー上では、SMB 接続が受け付けられて、SMB 要求が NTFS およびローカル記憶域スタックを通じてローカル ファイル システム操作として処理されます。srv.sys ドライバーは従来の SMB トラフィックを処理し、srv2.sys ドライバーは SMB 2.x以降のトラフィックを処理します。srvnet.sys コンポーネントは、両方の SMB プロトコルについてネットワークとファイル サーバー間のインターフェイスを実装しています。

  1. LanmanWorkstation と LanmanServer

Workstation サービスと Server サービスという名前は表示名であり、実際にはそれぞれ別の名前が存在します。LanmanWorkstation と LanmanServer です。これらの名前は各サービスのプロパティから確認することができます。レジストリから SMB の設定を変更されたことがある方は、これらの名前に見覚えがある方もいらっしゃるかもしれません。

Workstation サービスは LanmanWorkstation

Server サービスは LanmanServer

  1. Server サービスの処理がボトルネックとなっている例

一般的に、ファイル共有へのアクセスに時間がかかる場合、ネットワーク (SNP や SMB)、サーバーのパフォーマンス、サード パーティ製のソフトウエアなど様々な原因が考えられます。その中でも、Server サービスに関するパフォーマンス モニターの値が高い場合、Server サービスの処理がボトルネックとなっていることが疑われます。

具体的には、 Server サービスの負荷状態を確認するためには、 パフォーマンス モニターの Server オブジェクトや Server Work Queues オブジェクトを確認します。(もちろん、CPU 負荷やメモリの使用状況など一般的に負荷状況を確認する際のカウンタも確認します)

それぞれのオブジェクトのカウンターの詳細につきましては、パフォーマンス モニターの説明をご参照いただければと思いますが、今回はServer Work Queues オブジェクトの Queue Length 値に着目します。今回はそれぞれの意味についての説明は省略しますが、Queue Length のカウンタには、複数のインスタンスがあり、そのインスタンスで値が4 を超える状態が続くものがある場合、クライアントから要求された処理が滞留しているために、ファイル共有のアクセスに時間が掛っていることを疑います。

Server サービスは、クライアントからファイル共有の要求を受けると、その要求をキューに格納します。このキューに 格納された要求を Server サービスの各ワーカースレッドが処理を実施していきますが、それぞれの処理が遅延、あるいは大量の要求を受け付け、処理が追いつかない場合にキューに要求が滞留し、結果としてファイル共有へのアクセスが遅い事象が発生します。処理が遅延する原因としては、ディスクや CPU 処理に時間を要している場合、各処理に介在するフィルタドライバの処理で時間を要している (ウィルス対策ソフトウェアはフィルタ ドライバを使用するアプリケーションの典型的な例です)
ことが疑われますが、 以下のレジストリ値によりServer サービス自体のワーカー スレッド数 (MaxThreadsPerQueue) の最大値を増やすことで対策ができる場合もあります。

キー : HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters
名称 : MaxThreadsPerQueue
種類 : REG_DWORD
値 : Queue 1 個あたりのワーカースレッドの最大値
範囲 : 1 ~ 65535
デフォルト : 以下の値は、レジストリによる設定が行われていない場合の既定値となります。ワークキューは、従来のSMB用とSMB2.x以降用とで独立しており、それぞれに既定値が設定されています。

Windows Vista / Windows Server 2008
SMB: 10
SMB2: 10

Windows 7 / Windows Server 2008 R2
SMB:10
SMB2: 20

Windows 8 / Windows Server 2012
SMB:10
SMB2/3: 20

  • レジストリ エディタを使用し、MaxThreadsPerQueue のレジストリ値を追加 (値が既に存在する場合は変更) します。
  • レジストリの設定後は OS の再起動が必要です。
  • ひとまず MaxThreadsPerQueue のレジストリ値に 50 を設定していただき、事象が改善が見られるかどうか確認をお願いいたします。
  • 設定を行った場合、SMB/SMB2/SMB3いずれも「同じ値」に設定されます。例えば、Windows Server 2008 R2において、このパラメーターに50を設定した場合には、SMB/SMB2ともに、50のスレッドが使えるようになります。ただし、Windows Server 2008 において SMB2 で使用できるスレッドを増やす場合は、サポート技術情報 2761551 の修正プログラムを適用してから SrvMaxThreadsPerQueueという別のレジストリ値を変更する必要があります (SMB1 については MaxThreadsPerQueue で設定可能)。

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