FAQ

採用情報

PERFORCE

ID.931

Q. パフォーマンス改善のための一般的な推奨事項

A.


PERFORCEサーバ(P4D)のパフォーマンスは、多くの要素から影響を受けます。これらの要素はP4Dが実行されるマシンのハードウェアおよびオペ レーティング・システム、db.*ファイルが配置されているファイルシステム、そして運用環境におけるPERFORCEの使用方法に関連します。これらの うち、ある一つの側面の改善が特に有効な場合もありますが、一般的には、総合的にこれらの側面を改善することが、全体的なP4Dのパフォーマンス改善につ ながります。

最良のパフォーマンスを得るために、1台のマシンを単一のPERFORCEサーバとして専有することをお勧めします。専用のマシンとすることで、そのマシ ン上で利用可能なすべてのリソースを、単一のPERFORCEサーバが必要な限り使用できます。オペレーティング・システムのファイルシステム・キャッ シュにPERFORCEサーバのメタデータをキャッシュする場合、ファイルシステム・キャッシュを他のPERFORCEサーバや他のアプリケーションと共 有するよりも単独のPERFORCEサーバで専有する方が効果的です。


メモリ

P4D稼動マシンのメモリ、入出力サブシステム、およびプロセッサはすべて、パフォーマンスに影響を与えます。最新のオペレーティング・システムでは、処 理空間に不要なメモリのかなりの部分をファイルシステム・キャッシュとして使用するので、メモリ容量をできるだけ大きくすることが推奨されます。ファイル システム・キャッシュ内に納まる入出力要求は、納まらない入出力要求に比べて早く完了します。


ディスク・サブシステム

ファイルシステム・キャッシュを超える大きさの入出力要求については、入出力サブシステムでそれを改善できる可能性があります。db.*ファイルを含むス トレージ・サブシステムは、メモリ・キャッシュを備えているべきです。また、ストレージ・サブシステムのメモリ・キャッシュを最大にすることも推奨されま す。さらに、最良のパフォーマンスを得るためには、ライトバック・キャッシュを有効にしておくべきです。そのためには、当然ながらストレージ・サブシステ ムのメモリがバックアップ電源を備えている必要があります。db.*ファイルが格納されている論理ドライブへの入出力待ち時間は、物理ドライブ自身の回転 待ち時間も含め、最小限にとどめるべきです。入出力待ち時間を最小にするには、ホストとストレージ・サブシステムとが直接接続されている必要がある場合が あり、通常は最大の回転速度(例えば、毎分15,000回転)を持つ物理ドライブが必要です。

RAID 1+0(またはRAID 10)は、通常はより良好なRAID構成であり、db.*ファイルを配置した論理ドライブにも推奨されます。論理ドライブ内の物理ドライブの数も、P4D のパフォーマンスに影響する場合があります。一般的には、論理ドライブ内の物理ドライブの数が増加するのに応じて、パフォーマンスは向上します。必要とさ れるディスクの空き容量に対して、全体容量の小さな物理ドライブを使用する方が、より良いパフォーマンスを得られることがあります。また、論理ドライブの ストライプ・サイズがパフォーマンスに影響する場合があり、最適のストライプ・サイズは論理ドライブ内の物理ドライブの数に依存する場合があります。

ハードウェアベースのRAID実装(すなわち、ソフトウェアとして実装されたRAIDロジックでない)は通常、パフォーマンス特性に優れています。ソフト ウェアベースのRAID実装はCPUサイクルを必要とする場合があり、そうではなくとも、P4DプロセスがCPUサイクルを必要とする場合があるため、ソ フトウェアベースのRAID実装は避けるべきです。


ジャーナル・ファイルとバージョン化ファイルの場所

トラブルが発生した場合の修復を可能にするために、ライブ・ジャーナル(journal)は、db.*ファイルを含む物理デバイスとは異なるデバイスに配 置するべきです。また、ライブ・ジャーナルとdb.*ファイルとを分離させることは、パフォーマンス改善のためにも必要な措置です。db.*ファイルへの 書き込み処理の間に、エントリがライブ・ジャーナルに書き込まれ、レコードがdb.*ファイルに書き込まれます。ライブ・ジャーナルとdb.*ファイルが 同じ物理デバイス上にある場合、db.*ファイルへの入出力スループットが低下します。最良のパフォーマンスを得るために、ライブ・ジャーナルは別のホス ト・アダプタに接続された別のストレージ・サブシステム上に配置するべきです。ライブ・ジャーナルは、シーケンシャル書き込み用に最適化された論理ドライ ブおよびファイルシステム上に置くべきです。

バージョン化ファイルは、db.*ファイルおよびライブ・ジャーナルがある論理ドライブとは別の論理ドライブに置くべきです。最良のパフォーマンスを得る ために、バージョン化ファイルがある論理ドライブは、別のホスト・アダプタに接続された別のストレージ・サブシステム上に配置するべきです。バージョン化 ファイルは通常、かなり多くのディスク空き容量を必要とし、入出力スループットはdb.*ファイルほどは重要ではないため、バージョン化ファイルが格納さ れている論理ドライブにはRAID 5などのより経済的な構成を使用できます。


CPU

P4D稼動マシンのプロセッサおよびメモリが高速であれば、P4Dコマンドをより速く実行できます。コマンドによっては、処理の中で部分的に、他のコマン ドをブロックするようにリソースを取得します。そういった部分を可能な限り高速に実行することは、最良のパフォーマンスを得る上で重要です。例えば、ほと んどのP4Dコマンドには「計算フェーズ」がありますが、その間にいくつかのdb.*ファイルに対して共有ロックが実行されます。db.*ファイルに対す る共有ロックは、同じdb.*ファイルに書き込もうとしている他の処理をブロックします。コマンドの計算フェーズに必要なデータが、オペレーティング・シ ステムのファイルシステム・キャッシュの中にキャッシュされる場合、プロセッサおよびメモリ速度のみが計算フェーズを抑制します。したがって、P4D稼動 マシンのプロセッサおよびメモリをできるだけ高速にすることが、最良のパフォーマンスを得るためには重要であるということです。

PERFORCE環境では一般的に、P4D稼動マシンにおけるプロセッサ数やプロセッサのコア数を増やすよりも、より高速なプロセッサを用いることで、よ り良いパフォーマンスが得られます。ただし、プロテクション・テーブルやクライアント・ビューの設定が複雑である場合、CPUの必要条件に影響することが あります。CPU使用率は、"top"(LinuxおよびUnix)や "perfmon"(Windows)などのOSユーティリティを使用して監視できます。P4D稼動マシンのCPU使用率が高い環境で、既に高速なプロ セッサを使用している場合は、プロセッサの速度を維持するためにプロセッサ数を増やすか、プロセッサのコア数を増やす必要があるかもしれません。

プロセッサおよびオペレーティング・システムによっては動的周波数制御をサポートしており、動的にプロセッサ電圧とコア周波数を調整することによって、プ ロセッサが電力消費量を変えられます。プロセッサへの要求が多くなると電圧とコア周波数が増加し、プロセッサが最高速度に達するまで、P4Dのパフォーマ ンスに影響が及ぶ可能性があります。動的周波数制御による省電力化機能は、モバイル・コンピュータでは役立ちますが、P4D稼動マシンには推奨されませ ん。

動的周波数制御の二つの例を以下に示します。
Intel SpeedStep 一部のXeonプロセッサで利用可能であり、モバイル・コンピュータで一般的に利用可能
AMD PowerNow! サーバ・レベルのプロセッサを含む、AMDプロセッサのアレイで利用可能


これらの機能は、Linux(一部のSuSEディストリビューションではデフォルトで有効)、WindowsおよびMac OS Xの各プラットフォームでサポートされています。この機能がP4D稼動マシンで有効にされている場合、それを無効にすることを推奨します。いくつかの Linuxディストリビューション(SuSE等)では、"powersaved" サービスを "off" に設定することによって、この機能を無効にすることができます。

また、お使いのコンピュータの現在のプロセッサ速度を診断できる場合があります。Linuxでは、各コアの現在速度が、OSコマンドの "cat/proc/cpuinfo" の出力にある "cpu MHz" の行に示されます。


オペレーティング・システム

P4D稼動マシンのオペレーティング・システムの選択も、パフォーマンスに影響することがあります。32ビットのオペレーティング・システムは、大容量の 物理メモリに対処できない可能性があり、それによってファイルシステム・キャッシュの実質的なサイズが制限される場合があります。各種の64ビットのオペ レーティング・システムには、それぞれ独自のパフォーマンス特性があり、PERFORCEにおける特定の作業負荷に対して有効に働きます。一般的に、 Linux 2.6後期の64ビット・カーネルを使用するLinuxディストリビューションは、ほとんどのPERFORCEの作業負荷に対して良好なパフォーマンス特 性を持っています。


ファイルシステム

ファイルシステムのパフォーマンスは、オペレーティング・システムのパフォーマンスに大きく関係します。通常、種々のオペレーティング・システムは複数の ファイルシステムを提供しており、そのそれぞれが、特定のPERFORCEの作業負荷に有効に働く独自のパフォーマンス特性を持ちます。P4Dのパフォー マンスを最良にするためには、高いパフォーマンスのファイルシステムにdb.*ファイルを配置するべきです。一般的に、XFSファイルシステムは、ほとん どのPERFORCEの作業負荷に対して良好なパフォーマンス特性を示します。XFSファイルシステムは、Linux 2.6後期の64ビット・カーネルを使用するLinuxディストリビューションをはじめ、複数のオペレーティング・システムで利用可能です。

要求されている内容を予測し、ページをキャッシュから読み込むことにより、様々な入出力サブシステムのコンポーネントにおいて入出力を最適化します。この 最適化は、一般的に「先読み機能」として知られています。いくつかの実装では、先読みを調整することができ、それによってパフォーマンスが改善される場合 があります。しかし、先読みの調整には多少の技術が必要です。例えば、処理の中心がシーケンシャル読み込みである場合は、先読みサイズを大きくすることで パフォーマンスが改善される可能性がありますが、処理の中心がランダム読み込みである場合、画一的に先読みサイズを大きくすると、キャッシュされた有効な データが不必要に破棄される可能性があります。


PERFORCEの使用方法

PERFORCEの使用方法がパフォーマンスに影響することがあり、利用形態によってはパフォーマンスに直接影響する可能性があります。ディポのファイル 名は、いくつかの重要なdb.*ファイル(特にdb.rev、db.revhx、db.integed)において中核となるため、ディポ・ファイル名のパ スが長くなればなるほど、パフォーマンスは低下します。したがって、不必要に長いパス名を使用しないようにすることが望ましいと言えます。

また、開発手法もパフォーマンスに直接影響することがあります。完全なブランチを頻繁に作成することが要求される開発手法(例えば、バグ修正ごとにブラン チを作成)では、メタデータの量が急速に増加し、db.*ファイルのB-ツリー内により多くの層が発生します。層の数が増加すると、リーフ・ページをたど るためにより多くのキー比較および入出力要求が必要となるため、パフォーマンスに影響を与えます。また、完全なブランチを作成するということ自体に対して も、より多くのメタデータの読み取りと書き込みが必要になります。メタデータの読み取りと書き込みが増加すると、ファイルシステム・キャッシュに影響を与 え、他のPERFORCEタスクに悪影響を及ぼす可能性があります。完全なブランチを頻繁に作成するのではなく、各バグ修正に必要なファイルだけをブラン チするか、または一つのブランチに複数のバグ修正を導入できるような開発技法を検討した方がよいでしょう。


PERFORCEのアップグレード

PERFORCEでは、リリースのたびにP4Dの性能改善に努めています。一般的に、最新のP4Dリリースを使用することで、最良のパフォーマンスが得ら れます。なお、新しいP4Dリリースをセットアップする前には、そのPERFORCE環境において有効なデータと作業負荷で、一定規模の受け入れテストを 実施することをお勧めします。

<< PERFORCEに関するFAQ一覧へ戻る