Project Server 2013 のパフォーマンスに関するトラブルシューティング

概要: Project Server 2013 の一般的なボトルネックとその原因に関するトラブルシューティング情報を参照してください。
適用対象: Project Server 2013

パフォーマンスのテスト中、さまざまな種類の一般的なボトルネックがいくつかわかってきました。 ボトルネックとは、特定のファーム構成の容量が限界に達している状態です。 これによりファームのスループットが停滞または低下します。

[パフォーマンス モニター] セクションで指定されたガイドラインを使用してパフォーマンスを監視すると、Project Server 展開のパフォーマンスに影響を与えているボトルネックを、さらに効果的に特定できる場合があります。

一般的なボトルネック、原因、および解決方法

一般的なボトルネックとその原因、および考えられる解決方法を次の表に示します。

ボトルネック 原因 解決策
データベース競合 (ロック)
データベース ロックは、複数のユーザーが特定のデータのセットに対して競合する変更を加えることを禁止します。 データのセットがユーザーまたはプロセスによってロックされている場合、そのユーザーまたはプロセスがデータの変更を終了し、ロックを解除するまで、他のユーザーまたはプロセスはその同じデータのセットを変更することはできません。
データベース ロックの競合の発生を減らすには、次の方法があります。
データベース サーバーをスケール アップします。
読み取り/書き込み用のデータベース サーバーのハード ディスクを最適化します。
データベース サーバーのディスク I/O
ハード ディスクに対する I/O 要求の数がディスクの I/O 容量を超えると、要求はキューに入れられます。 その結果、各要求が完了するまでの時間が増加します。
複数の物理ドライブにデータ ファイルを分散すると、並列 I/O が可能になります。
特定のビューに表示するプロジェクトおよびフィールドの数を制限することで、データベース サーバーから要求されるデータ量を制限します。
使用するユーザー設定フィールドの数を、特にタスク レベルで制限してみます。 Project Professional から保存操作を行う場合、タスク レベルの数式フィールドは、データベース サーバーのディスク I/O の点で特に大きな負担になります。
フロントエンド Web の CPU 使用率
WFE がユーザー要求で過負荷になると、平均 CPU 使用率が 100% に近くなります。 これにより、WFE が要求にすぐに応答できなくなり、タイムアウトが発生してクライアント コンピューターにエラー メッセージが表示される場合があります。
この問題を解決する方法は 2 つあります。 1 つは、WFE サーバーをファームに追加してユーザーの負荷を分散する方法で、もう 1 つは、より高速なプロセッサを追加して Web サーバーをスケール アップする方法です。
サーバーのメモリ使用率
実行中の大きなキュー ジョブが多数あると、サーバーのメモリ使用率がスパイクする可能性があります。
より複雑なサーバー側スケジュールを計算する場合、つまりユーザー設定の数式フィールドを評価する場合にも、膨大なメモリ リソースが消費されることがあります。
その結果、各要求が完了するまでの時間が長くなります。
どの層のメモリ使用率がボトルネックになっているか、つまりアプリケーション サーバー、フロントエンド Web サーバー、またはデータベース サーバーにおけるメモリ不足を監視します。
メモリ不足を解決するオプションは 2 つあります。
その層に対して追加メモリを購入し、インストールします。
負荷を処理する追加のアプリケーション サーバーを購入します。
Active Directory 同期
Project Server のユーザーとリソースは、複数のドメインおよびフォレストにわたるサービスのユーザーと同期できます。 この機能は、大量のユーザーを手動で追加する、電子メール アドレスなどのユーザー メタデータを更新する、システム アクセスが不要になったユーザーを無効にするなど、管理者が単純作業を行う際に役立ちます。 Active Directory 同期は、手動で行うことも自動化されたスケジュールに従って行うこともできます。 同期処理を実行すると、リソースが大量に消費されます。
ユーザー使用率がピークの時間帯以外に Active Directory 同期を行うことをお勧めします。 これにより、Active Directory 同期によってユーザーのパフォーマンスが低下することはなくなります。
また、複雑に入れ子になったグループは使用しないようにします。このようなグループにより、実行する必要がある同期の複雑性が増し、同期処理にさらに時間がかかるようになります。
アプリケーション サーバー CPU
アプリケーション サーバー CPU は、以下の場合に大きな打撃を受ける可能性があります。
複雑なプロジェクトのスケジュールを設定する。
複雑なプロジェクトの数式を評価する。
時間単位のリソース計画の分析をオンにして、大量のプロジェクトでポートフォリオ分析を実行する。
アプリケーション サーバーの CPU 使用率を監視し、CPU リソースの使用率が高いと思われる場合は、アプリケーション サーバーをトポロジに追加して負荷を分散します。
アプリケーション サーバーを追加すると、データベース サーバーの負荷が増加する可能性があるスレッドが追加されることに注意してください。 これにより、データベース サーバーに新しいボトルネックが発生する可能性があります。これは、キュー設定でジョブ プロセッサ スレッドの数を減らすことによって解決される可能性があります。
データベース サーバー CPU
通常、大量のプロジェクト、および大量の表示フィールドで構成されるビューを読み込もうとすると、データベース サーバー CPU がスパイクします。 これにより、そのビューが適用されるときに、ユーザーの応答時間が短くなります。
特定のビューに表示されるプロジェクトおよびフィールドの数を制限します。

関連項目

Project Server 2013 でのパフォーマンスおよび容量の計画の概要

容量計画の戦略 (Project Server 2013)

パフォーマンスと容量に関するハードウェアの推奨事項 (Project Server 2013)

Project Server 2013 のスケール アップおよびスケール アウト トポロジ

Project Server 2013 でパフォーマンスを最適化する

Project Server 2013 のパフォーマンス カウンター

Project Server 2013 のパフォーマンスに関するトラブルシューティング

一般的なデータセット (Project Server 2013)