次の方法で共有

ケース スタディ: HP Proliant DL980 G7 8 プロセッサ ソケット システムでの IIS 8 スケーリング

提供元: Microsoft

このホワイトペーパーでは、HP と IIS 製品チームの共同の取り組みから得た結果をまとめ、HP の 8 方向システムで実行されている IIS のパフォーマンス機能を評価します。 このホワイトペーパーは、お客様がこのようなシステムで IIS を構成するために使用できる展開ガイドとしても機能します。

要約: このケース スタディでは、HP から 8 方向システムに Microsoft IIS 8.0 Server を展開して最適化する方法について説明します。

作成者: Hewlett-Packard (HP)、IIS 製品グループ (IIS)、Microsoft Enterprise Engineering Center (EEC)

はじめに

Web サーバー ワークロードは、通常、スケールアウト モデル上の汎用的なサーバーに関連付けられます。 追加の処理能力が必要な場合は、プールに追加のマシンが追加されます。 これは非常に一般的なモデルであり、Microsoft インターネット インフォメーション サービス (IIS) には、このようなアプローチを簡単に構成して展開できるようにするためのいくつかの機能があります。

通常、スケールアップ モデルは他のワークロード (SQL Server など) に関連付けられます。 しかし、実際には、Windows Server 2012 リリース中に、スケールアップ モデルをより適切に使用できるように IIS インフラストラクチャにいくつかの投資が行われました。 このような投資の結果として、IIS 8.0 は、このような大規模なサーバーのすべての特性を利用する方法で展開できます。 これにより、お客様はこのようなマシンのすべての力と信頼性を最大限に生かすことができます。

Windows Server 2012 開発サイクルの一環として、パフォーマンスの観点から IIS ワークロードを特徴付けるために一連のパフォーマンス テストが実施されました。 これらのテストは、Microsoft の Windows Server 用顧客検証施設である Microsoft Enterprise Engineering Center (EEC) の施設を使用して HP DL980 G7 で実施されました。

このホワイトペーパーでは、HP と IIS 製品チームの共同の取り組みから得た結果をまとめ、HP の 8 方向システムで実行されている IIS のパフォーマンス機能を評価します。 このホワイトペーパーは、お客様がこのようなシステムで IIS を構成するために使用できる展開ガイドとしても機能します。

お客様の問題

一般に、コアの数を増やすと、パフォーマンスが向上するはずです。 IIS のお客様は、Windows Server 2008 R2 を使用して Non-Uniform-Memory-Access (NUMA) 対応ハードウェアにアプリケーションを展開したときに、ある時点でコアの数が増加した後にパフォーマンスが低下することに気付きました。 これは、ソフトウェア メモリ同期のコストが、NUMA ハードウェア上の追加コアの利点を上回るためです。 Windows Server 2012 の IIS 8.0 では、NUMA ハードウェア上のプロセスのスレッド アフィニティをインテリジェントに分散することでこの問題に対処します。この概念実証により、オペレーティング システムとネットワーク IO チューニングを識別して IIS 8.0 の最適なスケーラビリティを確保することができました。

IIS 8.0

Windows Server 2012 のインターネット インフォメーション サービス (IIS) は NUMA 対応であり、IT 管理者に最適な構成を提供します。 次のセクションでは、IIS 8.0 が NUMA ハードウェアを利用して最適なパフォーマンスを提供する方法について説明します。

IIS では、次の 2 つの方法でワークロードをパーティション分割できます。

  1. "1 つのアプリケーション プール (つまり、Web ガーデン) で複数のワーカー プロセスを実行します。"
    このモードを使用している場合、既定では、アプリケーション プールは 1 つのワーカー プロセスで実行するように構成されます。 パフォーマンスを最大化するために、ワーカー プロセスと NUMA ノードの間に 1 対 1 のアフィニティが存在するように、NUMA ノードと同じ数のワーカー プロセスを実行することを検討する必要があります。 これを行うには、[最大ワーカー プロセス数] AppPool の設定を 0 に設定します。 この設定を構成すると、IIS によってハードウェアで使用可能な NUMA ノードの数が決定され、同じ数のワーカー プロセスが開始されます。
  2. "単一のワークロード/サイトで複数のアプリケーション プールを実行します。"
    この構成では、ワークロード/サイトは複数のアプリケーション プールに分割されます。 たとえば、サイトには、個別のアプリケーション プールで実行するように構成された複数のアプリケーションが含まれている場合があります。 実質的に、この構成により、ワークロード/サイトに対して複数の IIS ワーカー プロセスが実行され、IIS によって、パフォーマンスを最大化するためにプロセス アフィニティがインテリジェントに分散されます。

ワークロードに応じて、管理者はワークロードを複数のワーカー プロセスにパーティション分割します。 ワークロードが正しくパーティション分割されると、IIS 8.0 によって、IIS ワーカー プロセスが開始されようとしているときに最適な NUMA ノードが識別されます。 既定では、IIS によって、使用可能なメモリが最も多い NUMA ノードが選択されます。 IIS には、各 NUMA ノードによるメモリ消費量に関する知識があり、この情報を使用して IIS ワーカー プロセスが "負荷分散" されます。 このオプションは、Windows の既定のラウンド ロビンとは異なり、IIS ワークロード用に特別に設計されています。

最後に、IIS ワーカー プロセスから NUMA ノードへのスレッドのアフィニティを構成するには、2 つの異なる方法があります。

  1. "ソフト アフィニティ (既定)"
    ソフト アフィニティでは、他の NUMA ノードに使用可能なサイクルがある場合、IIS ワーカー プロセスのスレッドが、アフィニティ用に構成されていない NUMA ノードにスケジュールされる可能性があります。 このアプローチは、システム全体で使用可能なすべてのリソースを最大化するのに役立ちます。
  2. "ハード アフィニティ"
    ハード アフィニティでは、システム上の他の NUMA ノードでの負荷に関係なく、IIS ワーカー プロセスのすべてのスレッドは、上記の設計を使用してアフィニティ用に選択された NUMA ノードに割り当てられます。

ハード アフィニティは全体的なパフォーマンスを向上させることができますが、ハード アフィニティを設定するには、より多くの構成とハードウェアに関するより深い理解が必要です。 また、正しく構成されていない場合は、パフォーマンスも低下します。 そのため、既定の構成はソフト アフィニティです。

HP プラットフォーム

HP DL980 G7 の背景

DL980 G7 は、スマート CPU キャッシュと冗長システム ファブリックを備えたノード コントローラーを組み込んだ HP PREMA アーキテクチャを使用した、8 つのプロセッサ ソケットを備えた最初の HP Proliant スケールアップ サーバーです。 DL980 G7 サーバーの最初のイテレーションでは、Intel® Xeon® プロセッサ 7500/6500 シリーズ (Nehalem-EX ともいう) プロセッサ (4、6、8 コア SKU)、128 個の DIMM ソケット、16 個の PCIe スロットが使用されました。 2 番目のバージョンでは、Intel® Xeon® プロセッサ E7-8800/4800/2800 (Westmere-EX ともいう) プロセッサ (最大 10 コア SKU) がサポートされています。 現在の Intel Nehalem-EX 構成 (8 プロセッサ、それぞれ 8 コア、ハイパー スレッディングが有効になっている) の場合、Windows Server 2008 R2 では、合計 128 個の論理プロセッサ、2 TB の RAM と 16 個の PCIe スロットの最大 OS サポートが有効になります。 Intel Westmere-EX 10 コア SKU プロセッサとハイパー スレッディングが有効になっている場合、Windows Server 2008 R2 では DL980 G7 に対して合計 160 個の論理プロセッサが有効になります。 現在、Windows Server 2012 では、このプラットフォームでサポートされている 4 TB の RAM が有効になっています。

HP スケーラビリティ ノード コントローラーを備えたこれらの 8 方向 Intel ベースのサーバーのパフォーマンスとスケーラビリティの機能は、以前に Intel/AMD に存在していたものを超え、多くの UNIX プラットフォームのパフォーマンスを満たすか超えています。これは UNIX プラットフォームよりもかなり低い価格で行われます。 さらに、これらの新しい Nehalem-EX と Westmere-EX は、Gartner や他の業界アナリストによると、R.A.S 機能セットに関して UNIX プラットフォームとほぼ同等です。

HP DL980 のインストールと構成は、以前のシンプルな SMP サーバーとはさまざまな点で異なります。

  • HBA およびネットワーク カードなどの PCIe カードの配置が重要である
  • デバイス ドライバーは Windows KGROUP 対応および NUMA 対応である必要がある

Windows Server 2012 によるスケールアップ サーバーのサポートは大幅に改善されていますが、以前の Windows オペレーティング システムのバージョンとアプリケーションでは、DL980 G7 プラットフォームで完全にサポートおよびスケーリングするための正しいバージョンとパッチである必要があります。

Windows x64 Server とそのユーザー ワークロードでは 8 つ以上のソケットを使用する構成を利用するため、HP DL980 G7 のようなこれらのプラットフォームの構成や使用が正しくないと、パフォーマンスが大幅に低下する可能性があります。 この 8 プロセッサ構成の場合、正しくないデバイス ドライバーや NUMA に対応していないアプリケーションでは、ユーザーが期待した可能性があるスケーラビリティの向上を実現できないことがあります。 発生する可能性がある一般的な問題には、QPI、IO Hub、PREMA チップセットが相互接続する非スケーラブルなトランザクションのフラッディングが含まれます

Microsoft SQL Server、SAP、IIS の各チームは、DL980 G7 で製品の広範なテスト、展開、ベンチマークを行い、優れた結果を示しています。 HP DL980 G7 およびその他の 8 プロセッサ システムでは、データベース サーバーとして優れた成果が示されていますが、現在はインターネット インフォメーション サーバーとしてもそのように示されています

次の図は DL980 G7 ブロック図を示しています。リーダーは次の段落で示すさまざまな構成オプションとチューニングに従うので、利便性を考慮して提供されています。

D L 980 G 7構成の図。

構成のオプション：

DL980 G7 はさまざまな構成で出荷される: 4 および 8プロセッサ ソケット モデルを利用できます。 さらに、PCI 拡張スロットにはいくつかの異なる構成があります。 これらは DL980 の HP テクニカル リファレンス ガイドに記載されています

このドキュメントでは、Windows でプロセッサが認識および説明される方法、プロセッサ 0 から 7、NUMA ノード 0 から 7 について説明します。

D L 980 G 7 の上下のプロセッサ トレイの写真。

DL980 G7 には 2 つの "トレイ" があります。 上部トレイではプロセッサ 0 から 3 が保持され、メインおよびサブ IO ボードが直接制御されます。 下部トレイではプロセッサ 4 から 7 が保持され、"オプション" またはロー プロファイル (LP) IO ボードが制御されます。

DL980 G7 には次の 3 つの IO ボードがあります。

D L 980 G 7 の I/O 拡張スロット・オプションの図。

  1. メイン PCI ボード - プロセッサ 0 から 1 に 直接接続されており、このボードでは、フル ハイト HBA、NIC および FusionIO/SSD カードなどの高帯域幅 PCI デバイスに適した 5x PCIe Gen 2 IO スロット [2 (x8) および 3 (x4) 電気コネクタ] が提供されます。また、LAN On Motherboard (LOM -NC375i)、ビデオ、内部ディスク コントローラー　(Smart アレイ P410i)、SATA DVD、USB ポートなどの埋め込みデバイスも接続されます。
  2. サブ IO PCI ボード (省略可能) - プロセッサ 2 から 3 に直接接続されており、このボードでは、フルハイト高帯域幅デバイスに適した 5 PCIe Gen2 スロット [4 (x8) および 1 (x4) 電気コネクタ] と 1 PCIe Gen 1 (x4) - スロット ID 1 - (必要に応じて PCI-X スロット - 推奨されません) が提供されます。
  3. ロー プロファイル (LP) IO ボード - プロセッサ 4 から 5 に直接接続されており、このボードでは 4 x PCIe x8 および 1 x PCIe x4 スロットが提供されます。 これらのスロットはハーフ ハイトのみであり、最も最近のネットワークおよび HBA カードはハーフ ハイト スロットに合うように標準的なものを取り替えることができるロープロファイル ブラケットと共に出荷されます。

推奨される構成と設定

RAM

DL980 G7 には非常に強力なプロセッサがあり、それぞれに 2 つのメモリ コントローラーが含まれており、正しく構成すると大量の IO スループットを実現できます。 プラットフォームは、メモリ アクセスが各プロセッサの両方のメモリ コントローラーに均等に分散されるように構成されています。 "バランスの取れた" システム設計を確実に行うために、2011 年 5 月時点の 1 TB の RAM を備えたより一般的な展開で、少なくとも 512 GB の RAM をお勧めします。 512 GB から 1 TB 未満の RAM を搭載した DL980 G7 では、RAM が不十分なため、おそらく非常に強力なプロセッサを利用することはできません。 ほとんどのお客様は、この Windows オペレーティング システム バージョンでの IO NUMA 認識の向上と NUMA スケーリングの向上により、Windows Server 2012 での IO とスケーリング パフォーマンスの両方で IOPS の大幅な低下と大幅な改善を見ることができます。

次のメモリ構成の事実に注意してください。

  • DDR3 DIMM のみ。

  • 各プロセッサは 2 つのメモリ ライザーに接続され、各ライザーでは 1 つのメモリ コントローラーと 8 個の DIMM コネクタがサポートされます。

  • 登録済み DIMM (RDIMM) のみをサポートします。 バッファーなし DIMM (UDIMM) はサポートされていません。

    • LR または DDR3L は、Westmere-EX プロセッサでのみサポートされます。

  • シングルランク (SR)、デュアルランク (DR)、クワッドランク (QR) DIMM モジュールをサポートします

  • Nehalem-EX プロセッサでは 1 GB と 2 GB の DRAM テクノロジがサポートされ、4 GB は Westmere-EX プロセッサでもサポートされます。

  • DIMM は、2 つのメモリ コントローラー間でクワッドに追加されます。

  • Advanced ECC、Online Rank Sparing および Mirroring をサポートします。

  • メモリ ECC のサポートには、x4 および x8 チップ障害の修正が含まれます。

ネットワーク

  • ギガビット ネットワーク アダプターが標準として推奨されます。 これらの強力なシステムでは、1 ギガビット ネットワーク アダプターがボトルネックになる可能性が最も高くなります。
  • 必要なネットワーク パフォーマンスを実現するために必要なネットワーク アダプターの合計数を減らします。
  • 10 ギガビット ネットワーク アダプターにより、デバイス ドライバーとデバイス ドライバーの構成オプションが大幅に改善されました。
  • HP 10Gb NC550SFP (Intel) ネットワーク カードがテストされ、非常に高パフォーマンスであることが証明されました。完全なパフォーマンスを実現するには、メインまたはサブ IO ボード上に PCIe x8 スロットが必要です。
  • HP DL980 では、NC550SFP や NC523SFP などの最大 4 個の 10 GbE NIC がサポートされており (最新情報については HP DL980 クイック スペック ドキュメントを参照)、合計 8 個の 10 GbE ポートが備わっています。
  • 負荷分散のために、メインとサブの IO ボード間で 10 ギガビット カードのバランスを取ることができます (例: メイン ボードでは 2 x デュアル ポート 10 G NIC、サブ IO ボードでは 2 x デュアル ポート 10 G)。
  • リーダーは IIS スケーリング ペーパーで認識するため、より最新のネットワーク アダプターと最新のデバイス ドライバーで Receive Side Scaling (RSS) を有効にすることをお勧めします。 通常、1 ギガビット ネットワーク アダプターでは最大 8 個の RSS "リング" または "キュー" のみがサポートされます。 10 ギガビット アダプターでは少なくとも 16 個のリング/キューがサポートされます。 Receive Side Scaling は、複数の論理プロセッサ間で DPC オフロードのバランスを取るメカニズムです。 これにより、1 つのプロセッサでのみ高いカーネル時間が見られる非常に高いネットワーク アクティビティ中に発生することがある問題が回避されます (多くの場合、論理プロセッサは 0 または 1 ですが、必ずしもそうではありません)。 注: Windows Server 2008 R2 の RSS 実装では、プロセッサの最初の Windows KGROUP (KGROUP#0) の論理プロセッサのみが対象となりますが、Windows Server 2012 ではこの制限が排除され、最初のインストール時にいくつかの受信トレイ ドライバーでサポートされています。

HBA と IO

  • 高ストレージ IO アプリケーションの場合は、少なくとも 2 x デュアル ポート HBA をインストールします。より一般的な構成は、4 x デュアル ポート HBA です。
  • すべての HBA ポートが接続され、アクティブであることが重要です。 マルチ MPIO ソフトウェアを正しくインストールして構成する必要がある場合。 HP EVA シリーズ SAN には、自動負荷分散 (ALB) をお勧めします。
  • HBA によって設定が異なり、SAN モデルによって機能が異なりますが、一般的なガイダンスとして、以下をお勧めします。
  • Emulex - ほとんどの構成では、"OC Manager / HBA Anywhere" で HBA キューの深さを約 64 から 254 に設定します
  • QLogic - "SanSurfer" で実行スロットルを 64 から 96 に設定します
  • Brocade - キューの深さは Brocade 管理ガイドに記載されています
  • HBA カードを配置する必要がある: カードは、PCIe インターフェイスの特性に従って、3 つの IO ハブすべてに分散する必要があります。 常に x8 対応カードを x8 スロットに挿入し、その完全な機能の利点を得て、システム全体の負荷のバランスを取る傾向があります。

FusionIO デバイスに関する特別な注意事項 (通常は他の SSD カードに適用可能):

FusionIO (HP IO アクセラレータ ボード) と OCZ では、超高速アクセス (機械式ディスクより最大 10,000 倍高速) が提供されます。 これまで、広範なテストは FusionIO カードでのみ行われています。 次のような結果が得られたのは例外的です。

  • 少なくとも、FusionIO 2.2.3 以降のデバイス ドライバーである K-Group 対応 (FusionIO Web サイトから入手できます) を使用します。

  • FusionIO カードをメインまたはサブ IO ボードにのみ配置する: これらはロー プロファイル カードではありません。 推奨される IO スロットは、3、5、9、11 です。

  • 4 つを超える HP IO アクセラレータを使用する場合は、BIOS 内で変更を加えてさらに冷却できるようにする必要があります。また、外部電源ケーブルを検討するか、VSL 3.x で FusionIO 電源オーバーライド機能を使用し、PCIe スロットから追加電源を供給できるようにする必要があります。

  • 現在の FusionIO スタックにはまだスケーラビリティの向上が必要であり、FusionIO では引き続きそれらに取り組んでいます。 一方、このシステムの Fusion IO カードの数が多いほど、100 万 IOPS を超え、16 GB/秒を超えることに注意してください。 現在の FusionIO ドライバーの実装では、次のことがわかります。

    • 論理プロセッサのサブセットでのプロセッサ使用率が非常に高い。 これは、現在の FusionIO HBA で MSI-X がサポートされず、各 HBA では単一の論理プロセッサに割り込みが送信されるという事実に関連しています。 さらに、現在の実装では、各 HBA の DPC と FusionIO 完了ワーカー スレッドのみがサポートされています。 需要の高いスケーリング IO ワークロードの場合は、ユーザーが、これらの特定の論理プロセッサの CPU 使用率を 100% またはほぼ 100% で確認することで、これらの論理プロセッサを識別することがほぼ予想されます。 FusionIO では、これらのタスク専用の論理プロセッサを指定できるようにすることで、これを部分的に軽減するために使用可能な構成パラメーターが作成されています。 これらの高い IO CPU 時間では、これらの論理プロセッサを回避するために、アプリケーション レベルでアフィニティ マスクを使用できます。
    • IO スループットの不均衡。 最適な IO パフォーマンスは、FusionIO 完了スレッドが実行されるのと同じソケットで読み取り/書き込み要求を生成することによって得られます。 DL980 G7 BIOS では、Windows オペレーティング システムおよびその IO コンポーネント (使用およびチューニングするミニポートの storport と ndis/netio) に IO NUMAness が提供されます。
    • SSD のクリーンアップの影響によるスループットの変更、SSD の前世代と現在の世代で見られる問題。

BIOS

IIS 用 DL980 G7 BIOS では、次の既定値を変更することをお勧めします。

設定名 推奨設定 既定の設定
HP 電源プロファイル Custom (既定のバランスの取れた電源とパフォーマンス)
HP 電源レギュレータ OS コントロール モード (既定の HP ダイナミック省電力モード)
プロセッサ ハイパースレッディング IIS 8.0 ワークロードの種類とハイパースレッディングの影響については、以下の段落を参照してください Enabled
最小プロセッサ アイドル電源状態 C 状態なし (プロセッサ電力利得なし) "または" C1e (プロセッサ電力利得と十分なパフォーマンスを引き続き得るため) (既定の C6 状態)
メモリ電源キャッピング 無効 (既定では有効)
協調電力制御 無効 (既定では有効)
MPS テーブル モード フル テーブル APIC (既定値)。
アドレス モード 44 ビット Enabled (既定では無効)
熱構成 多くの HP IO アクセラレータ/Fusion IO HBA を使用している場合は、増強冷却または "最大ファイン (吹き出し)"。 (最適冷却)
Windows デバッグ: ASR 状態 (デバッガーがアタッチされていない場合は無効) OS デバッガーがアタッチされている場合は無効。 (既定では有効)
Windows デバッグ: iLO Cli (iLO セッションから) OS デバッガーがアタッチされている場合は無効。 (既定では有効)

DL980 G7 プラットフォームでは、Windows Server 2012 によって、x2APIC モードおよび物理割り込み配信モードでプロセッサと IOH が自動的に切り替えられます。 Windows Server 2008 R2 SP1 で x2APIC を有効にして IO スケーリングを改善するには、いくつかの Windows QFE をプラットフォームにインストールし、追加の Opt-In BCDEDIT コマンドを実行する必要があります。 x2APIC の有効化と QQFE の仕様については、Microsoft サポート技術情報データベースに示されています

ファームウェア

たとえば、2012 年 10 月のリリースで多くの IO NUMA の機能強化が追加されたなど、以下のコンポーネントのファームウェアが利用可能な最新の状態に更新されていることが重要です。

  • DL980 G7 システム
  • HBA カード
  • ネットワーク カード
  • FusionIO カード (使用されている場合)

HP DL980 サポート Web サイトでこれらのコンポーネントのファームウェアを確認することを強くお勧めします。

Windows のバージョンと構成

Windows のお客様向けの Mission Critical オファリングの一環として、HP には、最新の重要な Microsoft QFE を使用して Windows を自動的にセットアップおよびチューニングするための Smart Update QFE CD があります (https://www.hpe.com/us/en/servers/smart-update.html)。 これらの更新とチューニングは、Microsoft と共に実装され、HP DL980 ラボで検証されています。 HP では、これらの更新の実行をお客様に推奨しています。

  • Windows Server 2012 - カーネル モード、キャッシュ管理、要求と接続管理、およびユーザー モードの IIS 設定は Windows Server 2008 R2 から変更されていません。「Windows Server 2008 R2 のパフォーマンス チューニング ガイドライン」ドキュメントで説明されている IIS 固有のチューニングを参照してください。 .
  • Windows 2008 R2 の場合は、SP1 以降をお勧めします。 Service Pack 1 には、> 64 論理プロセッサのサポートに関する重要なパフォーマンス修正プログラムが多数含まれています。
  • Windows 2008 では、44 ビット アドレス指定を正しくサポートできないため、DL980 G7 にインストールしないでください。 何らかの理由で Windows 2008 (R2 以外のバージョン) が DL980 に展開され、ハイパー スレッディングと 44 ビット メモリの両方を無効にする必要がある場合、システムは 64 個の論理プロセッサと 1 TB の RAM に制限されます。 Windows Server 2008 SP2 は、HP DL980 G7 でサポートされている唯一の Windows Server 2008 Server バージョンです。 Windows Server 2008 が引き続き必要な場合は、HP DL980 G7 の Windows Server 2008 SP2 用 Windows QFE の完全な一覧について、HP サポート Web サイトと組織を参照してください。

テスト手法

テスト シナリオ

このテストの目標は、NUMA 対応ハードウェア上の CPU コア/ソケットの数を増やしながら、IIS サーバーのスケーラビリティをテストすることです。

  • シンプルな ASP.net 動的テスト ページは、Web サイトのコンテンツとして使用されます
  • HTTP 要求を生成するために Web 容量分析ツール (WCAT) が使用されます
  • HP Core Disable ユーティリティは、IO 構成を考慮しながら、CPU コアとソケットを無効にしてサーバーをスケールダウンするために使用されます

テスト環境では、IIS 8.0 を実行する NUMA ハードウェアを使用するサーバー上で ASP.NET Web アプリケーションがどのようにスケーリングされるかを示します。 目標は、展開時に 100% またはほぼ 100% の CPU 使用率で処理された 1 秒あたりの要求数を決定するようにサーバーにストレスをかけることです。

"IIS のパフォーマンスを測定するために次の構成が使用されました"

  1. Web ガーデン (1xN) - 単一アプリケーション プール、ソケットごとに 1 つのプロセス。 これは、単一アプリケーションをスケールアップする必要があるエンタープライズ シナリオを表します。
  2. ホスティング (Nx1) - ソケットごとに 1 つのアプリケーション プール、アプリケーション プールごとに 1 つのプロセス。 これは、複数のアプリケーションが単一サーバーでホストされるホスティング シナリオを表します。
  3. 既定値 (1x1) - ソケットの数に関係なく、1 つのアプリケーション プールと 1 つのプロセス。 これは、すぐに使用する構成を表します。

20/40/80 コア (2/4/8 プロセッサ ソケット) に対してテストが繰り返されました。 また、180 コア (ハイバー スレッディングが有効) の追加テストを実施して、IIS が HT からどのように利点を得られるかを確認しました。

テストの設定

サーバー

合計 6 台のマシンを使用して試験を実施しました

  • WCAT クライアントとして動作する 4 台のマシン (WCAT 設定: 物理クライアントあたり 100 仮想クライアント)
  • WCAT コントローラーとして動作する 1 台のマシン
  • IIS 8.0 サーバーとして 1 台の HP9L980G7

ネットワーク

テスト環境は、4 台のクライアント マシンと 1 台のサーバーで設定されました。 各クライアント マシンでは 4 つの 1 Gb NIC が使用されました。 サーバーでは 16 個の 1 Gb NIC が使用されました。 16 個のサブネットが構成され、各クライアント NIC が一意のサーバー NIC にペアリングされました。

RSS 設定

サーバーのネットワーク パフォーマンスは、RSS 設定を使用して最適化されました。

特定の NIC で受信されたトラフィックが NIC と同じ IO ハブ上のコアによって確実に処理されるように、各 NIC は NumaNode 設定を使用して同じ IO ハブ上の NUMA ノードに関連付けられました。

すべての NIC の RSS キューの合計数は、マシン上の論理プロセッサの合計数と同じになりました。 これは、NIC ごとに NumberOfReceiveQueues を設定することで行われました。

その後、各 NIC の RSS キューは、BaseProcessorNumber と MaxProcessors の設定を使用して割り当てられた NUMA ノード上の特定のコア セットにマップされました。

結果

次のグラフは、CPU コアの増加に伴う IIS のパフォーマンス (1 秒あたりの処理要求の数) の変化を示しています。

CPU コアの数を 20 から 40 に増やす (2 ソケットから 4 ソケット):

20 のコア数がベースラインとして使用されます。 CPU の数が 20 から 40 に増加すると、Web ホスティング シナリオで処理される要求が 67% 増加し、Web ガーデン シナリオでは 41% 増加し、既定のシナリオでは 2% 減少したことがわかりました。 これは、ホスティングと Web ガーデンの両方のシナリオで、CPU コアの増加の利点を最も得られることを示しています。 NUMA ハードウェアを利用するために単一プロセスをスケーリングできないため、既定の構成では CPU の増加を利用できません。

80 コアと 40 コアの比較

コアの数を 40 から 80 に増やした後も、同様の傾向が見られました。 ホスティング シナリオでは 64% 以上の要求を処理でき、Web ガーデンのシナリオでは 31% 以上の要求が処理されました。 さらに既定の構成パフォーマンスは 3% 低下しました。

80 コアと 40 コアの C P U コア間の R P S スケーリングを比較した縦棒グラフ。

ハイパースレッディングの影響

ハイパースレッディングを有効にした後、ホスティング構成では 18% 以上の要求が処理されました。 Web ガーデンの構成では 4% 以下の要求が処理されましたが、既定の構成では 3% 以上の要求が処理されました。 通常、HT では最大 20% のパフォーマンスを向上させることができます。 ホスティング構成では HT を最大限に活用することができます。

ハイパースレッディングを有効にした結果を比較する縦棒グラフ。

まとめ

IIS 8.0 は NUMA ハードウェア対応であり、以前の IIS バージョンとは異なり、NUMA ハードウェアで積極的にスケーリングできます。

IIS 8.0 のスループットは、CPU ソケットを 2 から 4 に増やすと 67% 増加し、CPU ソケットを 4 から 8 に増やすとさらに 64% 増加しました。 ハイパースレッディングを有効にすると、スループットがさらに 18% 増加しました。

HP Proliant DL980-G7 では、需要の高い IIS アプリケーションを展開するための堅牢なプラットフォームが提供され、HW の信頼性、可用性、保守性がより高いプラットフォーム上のサーバー統合ソリューションを使用してアプリケーションのスケーラビリティが提供されます。

IIS 展開のスケーリングをお考えのお客様は、NUMA 対応ハードウェアに IIS を展開することを検討し、スケールアップとスケールアウトの両方のオプションの利点を得る必要があります。

HP DL980-G7 での HyperV Server 2012 展開を使用した IIS 8.0 のより多くの特性評価が検討されており、これらの結果も共有されます。

付録

PowerShell

背景

従来、マルチソケット システム上の各プロセッサは、同じバスを介してメモリと IO にアクセスします。 大規模なシステムでは、バスのボトルネックを回避するために NUMA (Non-Uniform Memory Access) を使用することがますます一般的になっています。 このモデルでは、IO とメモリのさまざまな部分がさまざまなソケットに接続されるため、IO とメモリ操作のパフォーマンスは、ソケットがメモリと IO の一部にどの程度近く接続されているかに影響を受けます。

Receive Side Scaling (RSS) を使用すると、複数のプロセッサによるネットワーク受信の処理が可能になります。

RSS アフィニティの構成

Windows Server 2012 以降では、PowerShell を使用して、特定の NUMA ノードへの RSS アフィニティを構成できます。 コア ネットワーク チームは、RSS スタックを完全に制御できる一連のコマンドレットを提供する素晴らしい仕事をしました。

より具体的に言うと、NUMA アフィニティは、Set-NetAdapterRSS コマンドレットを使用して構成できます。 このコマンドレットでは、サーバーのハードウェア トポロジに関連するいくつかのパラメーターを受け取ります。 パラメーターは、BaseProcessorGroup、BaseProcessorNumber、MaxProcessors、NumaNode です。

このようなプロパティの値を収集するには、手動と PowerShell の使用の 2 つの方法があります。

NUMA アフィニティ設定を正しく構成するには、特定の NUMA ノードへのネットワーク アダプターの物理的な接続を識別することが不可欠です。

手動によるトポロジ情報の収集

現在、このプロセスは次の手順で構成されます。

  1. [コントロール パネル]\[ネットワークとインターネット]\[ネットワーク接続] を使用して、ターゲット ネットワーク アダプターを見つけます。 次の手順の "デバイス名" の対象となるプロパティは次のスクリーンショットのとおりです。
    コントロール パネルの [ネットワーク接続] タブのスクリーンショット。デバイス名フィールドが強調表示されています。
  2. デバイス マネージャーを使用して NIC を見つけます。 そのため、前の手順で収集した "デバイス名" プロパティを使用します。
    [デバイス マネージャー] タブの [サーバー マネージャー ウィンドウ] のスクリーンショット。展開されたメニューでデバイス名が強調表示されます。
  3. 指定した NIC のプロパティ ダイアログを呼び出します。 [全般] タブには、特定の NIC のスロット、デバイス、関数の番号が表示されます。
    [全般] タブの [プロパティ] ダイアログ ボックスのスクリーンショット。場所の出力が強調表示されています。
  4. バス情報を手元に置いて、NIC が接続されている NUMA ノードを特定することができます。そのためには、上記の "ハードウェア セクション" で説明したように、この情報をハードウェア トポロジ図に関連付けます。
PowerShell を使用したハードウェア トポロジの収集

正しい RSS アフィニティ値の設定に使用できるハードウェア トポロジ情報は、TechNet ギャラリー (https://gallery.technet.microsoft.com/Device-Management-7fad2388) で入手できる Device Management PowerShell コマンドレット サンプルを使って取得できます。 このサンプルでは、デバイスを列挙、制御、管理するためのコマンドレットが提供されます。

このモジュールでは現在、次のコマンドレットが公開されています。

  • Get-Device
  • Get-Driver
  • Get-Numa
  • Enable-Device
  • Disable-Device
デバイスと NUMA トポロジ情報の一覧表示

Get-Device | -Object -Property Name | ft Name、NumaNode、UINumber -AutoSize

論理プロセッサと NUMA 情報

Get-Numa

ファームウェア テーブル

$hardwareTopology = Get-Numa; $hardwareTopology

WCAT

Web Capacity Analysis Tool (WCAT) は、主に制御された環境内の Web サーバーのパフォーマンスを測定するために設計された軽量の HTTP 負荷生成ツールです。 WCAT では、単一の Web サイトまたは複数の Web サイトに対して要求を行う数千人の同時ユーザーをシミュレートできます。

これは https://www.iis.net/downloads/community/2007/05/wcat-63-(x86) にあります

バージョン情報

IIS 製品グループ

Microsoft の IIS チームには、Windows Server の一部として IIS サーバーを出荷する役割があります。 また、このチームは https://www.iis.net/downloads にあるさまざまな関連製品をリリースし、維持しています。

Hewlett-Packard (HP)

Hewlett-Packard Company (HP) は、米国カリフォルニア州パロアルトに本社を置くアメリカの多国籍情報技術企業です。 消費者、中小企業、大企業 (政府、医療、教育分野のお客様を含む) に製品、技術、ソフトウェア、ソリューション、サービスを提供しています。 HP は、世界中の Microsoft Windows の収益とユニット数において世界をリードする企業です (2012 年 8 月 の IDC Worldwide Quarterly Server Tracker for 2Q12)。 HP Business Critical Server 部門内では、Mission Critical Windows Engineering ラボは堅牢な Microsoft Windows および SQL Server ソリューションを提供するために、10 年以上にわたる共同エンジニアリングを行ってきました。 この IIS スケーリング プロジェクトでは、チームは Microsoft IIS チームと緊密に協力して、最適なスケーラビリティとパフォーマンスを確保してきました。

EEC

Microsoft の Enterprise Engineering Center (EEC) は、その存在をシンプルなアイデア (検証とコラボレーション ラボで Microsoft のお客様に最高の機能を提供する) に負っています。

EEC には世界クラスのハードウェアが装備されており、非常に才能があり情熱的なチームが配置されています。 Redmond キャンパス (Microsoft の製品開発チームの中心) にあるため、Microsoft のお客様、パートナー、製品グループのエンジニアを集めて、明日のエンタープライズ ソリューションを検証することができます。