私は、IO に非常に敏感なアプリケーション (Accredo Saturn) を実行するサイトを持っています。これは、ローカル フラット ファイル データベースを使用して Delphi で記述された会計/CRM パッケージです。
さまざまな歴史的理由により、このサイトは Proliant DL380 G9 上の Server 2012 R2 Hyper-V で稼働する Windows Server 2008 R2 ターミナル サーバーで実行されており、DC は SBS 2011 を搭載した古い DL380 G7 でした (Exchange は長い間 Office 365 上にありました)。
私はそれらを Server 2019 を実行する新しい DL380 G10 にアップグレードしました。ホストとドメイン コントローラーは、P408i-p 上の RAID10 の 6x 600 GB 10k SAS (ホストは独自のパーティション、残りは 1 つの大きなパーティション) で実行され、リモート デスクトップ サーバーは P408i-a 上の RAID10 の 4x 480 GB 混合使用 SATA SSD で実行されています。サーバーには 2x Xeon 4210 と 64 GB のメモリがあります。このソフトウェアのデータは、リモート デスクトップ サーバーに直接マウントされた SSD アレイ上の VHDX にあります。
彼らには 18 人のユーザーがいて、全員がこのプログラムのリモート デスクトップ サーバーを使用しています。また、8 人のコールセンター ユーザーは Unify 電話システム エージェントも使用しています。1 人か 2 人は Edge を使用しています。このクライアントは速度にうるさいので、仕様を少しオーバーにするつもりでしたが、前述したようにソフトウェアはうるさいのです。
クライアントはソフトウェア内の速度が遅いと不満を述べています。テストしたところ、5 秒かかっていた操作が最大 15 秒かかるようになりました。同じハードウェア上の古い 2008 R2 VM はこれまでどおり動作しているので、ゲストに問題があるように思われます。
ユーザーがログインしていない状態で diskspd を実行しました (-c100b -b4K -o32 -F8 -T1b -s8b -W60 -d60 -Sh)。両方の VM で同様の読み取り IOPS とスループットを確認しましたが、新しい 2019 VM のスレッドには大きなばらつきがありました。ゲストでは約 531.41 Mbps と 136k IOPS を確認しましたが、2019 VM では 2 つのスレッドが 1.9 Mbps でダウンしています。古い VM は 520.44 Mbps ですが、1 つのスレッドが 3.75 でダウンしている以外は、スレッドあたり一貫して約 72 ～ 76 です。合計は 133k IOPS でした。これは SSD アレイ上の値です。
比較すると、同じパラメータを持つベアメタル SSD アレイでは、999 Mbps、スレッドあたり一貫して 124 ～ 125 Mbps、合計 255k IOPS が得られます。
これについて何日も調べています。レジストリ エントリを試して IO ロード バランサーを無効にしてみましたが、効果はありませんでした。2019 にも適用されるかどうかはわかりません。固定 VHDX と動的 VHDX の両方を試しました。サーバー間でデータ ボリュームをスワップしました (独自の VHDX です)。動的メモリと静的メモリを試しました。NUMA を有効または無効にしてみました。
私は途方に暮れており、明日から古い VM で今年のコールセンターを開始するクライアントがいてイライラしています。
2008 R2 は第 1 世代、バージョン 5 の VM ですが、2019 は第 2 世代、バージョン 9 です。
ミッション IOPS を回復するためのヒントがあれば、ぜひ教えてください。
これは私の最初の投稿なので、関連性や具体的な情報が十分でない場合はお詫び申し上げます。
答え1
6x 600 GB 10k SAS を RAID10 で使用
2x 高性能 SSD の RAID 1 の代わりに、IO が 50 倍になるのでしょうか?
一般的には、SSD を取得します。
上部には静的サイズの SSD を使用します。
できることはそれほど多くありません。ただし、数字は異常に聞こえます。200k を超える IOPS は、驚くほどひどいプログラミングを物語っています。
答え2
これは、パフォーマンスの問題がストレージに起因するという証拠ではありません。
遅いアプリケーション ワークフローを詳細に分析します。
どのようなコードパスが必要ですか? 各関数にかかる時間をプロファイルします。
どのようなデータベースクエリを実行しますか?
関係するデータ レコードの数はどれくらいですか? サイズはどれくらいですか?
- ファイルまたはデータベース ベースのロックを含む同時実行性はどのように処理されますか?
- ネットワーク経由で外部リソースを使用しますか? それらの遅延はどのくらいですか?
- 回線上でのクライアントへの通信はどのようになっているでしょうか? この場合、クライアントはターミナル サーバーである可能性があります。
おそらく、この詳細を調べるにはソフトウェア ベンダーの支援が必要になるでしょう。アプリケーション パフォーマンス監視パッケージから得られるような詳細なプロファイリングと可視性を求めてください。
CPU、メモリ、IOPS、ネットワーク帯域幅などのリソース制限が、速度低下の原因である可能性があります。これらは測定すべき指標です。ただし、その OS 上のアプリケーションのスタックは、ハードウェアを導入しても高速化しない可能性もあります。それを判断する唯一の方法は、実際に何が遅いのかを切り分けることです。
答え3
別の問題を調査するためにここに来たときに、これに気付きました。この問題は解決されましたが、原因は TSFairShare Disk でした。これを無効にすると問題は解決しました。これは、ファイル レベルのデータベースを使用する多くのアプリケーションで発生する問題であることがわかりました。
Microsoft Dynamics GP フォーラムに埋もれていた解決策を見つけました。実際の修正の詳細はここにまとめられています -https://www.ryslander.com/disable-fair-sharing-in-windows-server/- GP や使用していたアプリケーション (Accredo) などでは、FSSDisk のみを無効にする必要があり、その他はそのままにしました。
Server 2022 では、デフォルトが無効に戻っていることに注意してください。