サーバのパフォーマンスは、メモリが十分に確保されているかどうかに大きく依存します。これには2つの問題があります。第1の問題を回避するには、大量のクエリを実行中のサーバにページングをさせないようにします。第2の問題を回避するには、db.revテーブル(またはそのうち少なくとも実際に使用する分量)がメインメモリにキャッシュされるようにします。

したがって、1ファイルにつき1.5KBのRAM(100,000ファイルに対して150MBのRAM)が利用可能であれば、たとえすべてのファイルに関わる動作を実行しても、サーバはページングを行いません。もちろん、大規模な動作が複数同時に実行される可能性もありますから、ページングを回避するにはより多くのメモリが必要です。ただし、大多数の動作では、小規模なサブセットのファイルしか使用しません。

通常のインストレーションの場合、ディポの中で1ファイルにつき1.5KBのRAMがあれば十分です。

Perforceは、ディスクI/Oの使用に関して優れています。使用しているメタデータは検索しやすいうえに、データへアクセスする際には概してデータのなかでも限られたサブセットを順番にスキャンするという方法をとります。ディスクにもっとも負担がかかる動作はファイルのチェックインです。Perforceサーバがアーカイブのファイルの書き込みとリネームをしなければならない場合です。サーバのパフォーマンスは、オペレーティングシステムのファイルシステム実装に依存しており、とくに、ディレクトリの更新が同期式であるかどうかによって大きく左右されます。また、サーバのパフォーマンスは、基盤を成すハードウェアのI/Oサブシステムの性能にも大きく左右されます。

Perforceが特定のハードウェア構成やファイルシステムを推奨することはありません。とはいえ、Linuxサーバは(Linuxの非同期的ディレクトリ更新のおかげで)概して最も速く動作しますが、不適切なタイミングで電源が切れると、復旧に手間取ることがあります。それに比べると、(Solarisでも使用されている)BSDファイルシステムの動作は遅いですが、より信頼できます。NTFSのパフォーマンスは、LinuxとBSDの間の範囲に落ち着きます。

データベースとバージョンファイルがNFSマウント済みボリュームに保存されている場合、システムのパフォーマンスは、通常そのNFSの実装か、その基盤を成すストレージハードウェアに依存します。PerforceはSolarisのNFS環境でテストされ、サポートされています。

LinuxおよびFreeBSD上では、ファイルロッキングが比較的遅いので、NFSを介するデータベース更新に問題が生じるおそれがあります。これらのプラットフォーム上では、ジャーナルがNFSマウントされている場合、すべての動作が遅くなります。一般に(LinuxやFreeBSDでは特に)、Perforceのデータベース、ディポ、ジャーナルのファイルを、Perforceサーバプロセスを実行するマシンのローカルディスク上に保存することを推奨します。

上記の問題は、Perforceサーバプロセス(p4d)のみに影響します。Perforceアプリケーション(p4、Perforceコマンドラインクライアントなど)は、これまで常に、ユーザのホームディレクトリ中のクライアントワークスペースなどの、NFSマウント済みドライブ上のクライアントワークスペースでの稼働実績を挙げてきています。

Perforceが使用するディスク容量は、以下の3つの要素に依存します。

以上の3つの要素すべてが、使用中のデータの性質と、Perforceの使用度によって変わります。

必要なクライアントファイルスペースは、ユーザが任意の時点でクライアントワークスペース内に必要とするファイルのサイズと一致します。

サーバのデータベースサイズはかなりの精度で計算できます。推定で、1ユーザ1ファイルにつき0.5KB必要です。(例えば、1つのシステムにファイルが10,000個あり、ユーザが50人いれば、データベースに250MBのディスク容量が必要です。)データベースは、時間の経過とともに個々のファイルの履歴が増加するにつれて、規模を増していくことが予想されます。

サーバにあるバージョン化ファイルのアーカイブのサイズは、保存されているオリジナルファイルのサイズに依存するので、リビジョンの増加に応じて規模を増していきます。大多数のサイトでは、少なくともオリジナルファイルのサイズの3倍にあたるディスク容量を割り当てておきましょう。

db.haveファイルには、クライアントワークスペースで作業状態になっているファイルのリストが記録されています。したがってこのファイルのサイズはデータベース内の他のファイルと比べて急速に増大していく傾向があります。db.haveファイルのサイズに関する問題に直面しており、かつ大きなファイルを適切にサポートしているサーバにすぐに切り換えられない場合、使っていないクライアントワークスペース仕様を削除することでクライアントワークスペースのビューの範囲を狭めると、問題を多少改善できることがあります。

ディスク空き容量を監視するには、p4 diskspaceコマンドを使用します。デフォルトでは、p4 diskspaceを実行すると、ディスクの空き容量、使用中の容量、およびPerforceによって使用されるファイルシステムの総容量が表示されます。

デフォルトでは、P4ROOT、P4JOURNAL、P4LOG、TEMPを保持するファイルシステムの空き容量が10MBを下回ると、Perforceサーバがコマンドを受け付けなくなります。この動作を変更するには、filesys.P4ROOT.min構成可能変数(およびその他の関連する構成可能変数）に、希望の上限値を指定してください。

Perforceサーバプロセスを動作させるユーザアカウントにディスククオータが適用される場合、当該ファイルシステムに実際に残っている物理的な空き容量にかかわらず、filesys.*.min構成可能変数にはそれらのクオータが反映されます。

ディポ内の特定のファイルに現在占有されているディスク容量を見積もるには、管理中のサイトのデータ保存方法で使用されるのと同じブロックサイズをp4 sizesコマンドに指定します。例えば、

p4 sizes -a -s -b 512 //depot/...

というコマンドを使用すると、ブロックサイズを512バイトとして計算した場合の、//depot/...内にあるすべてのリビジョン(-a)の合計値(-s)が表示されます。

//depot/... 34161 files 277439099 bytes 5429111 blocks

p4 sizesにより報告されるデータは、実際にはファイルとクライアントワークスペースの同期に必要なディスク容量を反映しているのですが、それでもサーバ側でのディスク使用量の概算として参考にすることができます。

PerforceはTCP/IPネットワーク上で動作可能です。ネットワークの制約はまだ見つかっていませんが、帯域幅が広くなるほど動作は良好になるでしょう。

Perforceは各クライアントとサーバの通信にTCP/IP接続を使用します。サーバのポートアドレスはP4PORTで定義されますが、クライアントのポート番号はTCP/IPによって決められます。コマンドが完了して接続が閉じると、ポートはその後2分間にわたってTIME_WAITという状態になります。ポート番号は1025から32767までの範囲に及びますが、ふつう数100から数1000の番号だけが同時に使用される可能性があります。したがって、例えばスクリプトを使用してPerforceコマンドを何度も立て続けに呼び出すと、使用可能なポートがすべてふさがれる可能性があります。

デフォルトでは、アイドル接続中のキープアライブは行われません。ネットワークによってアイドル接続がサイレントに切断されると、その動作が原因となって想定外の接続の問題が発生するおそれがあります。(p4 pullスレッドがマスターサーバとリモートサイトのレプリカとの間でデータを転送する場合に注意しましょう。この場合、各サイトの営業時間やユーザの作業負荷しだいでは、1日に数時間にわたるアイドル接続が発生する可能性があります。)以下の4つの構成可能変数を使用して、アイドル接続の状態を管理することができます。

ネットワーク構成でキープアライブパケットが必要な場合は、例えば3600秒(1時間)や数十分単位の間隔など、適切な長さの値をnet.keepalive.idleに指定してください。

Perforceバージョン化サービスは、CPUのリソース消費量という観点からいえば、比較的軽量です。通常、Perforceサーバのインストール先プラットフォームを決定する際に、CPUの処理能力が主な懸案事項となることはありません。

ピーキングが有効になっている場合、以下のコマンドは読み取り専用ロックなしで実行されます。

以下のコマンドは一定条件下ではロックなしで動作します。大半の場合これらのコマンドは対象ファイルをロックせずに読み取りますが、いつも必ずロックなしで動作するという保証はありません。

db.peeking設定をコマンド単位でオーバーライドすることができます。それには、-Zpeeking=フラグを使用し、その後に任意の値を指定します。例えば、1つのコマンドのピーキングを無効にするには、以下のコマンドを実行します。

p4 -Zpeeking=1 fstat

そして以下の結果と比較します。

p4 -Zpeeking=2 fstat

読み取り専用ロックがパフォーマンスに悪影響を及ぼしているかどうか(また、ロックなしの読み取りを有効にした後でパフォーマンスがどれほど改善したか)判断するには、サーバログを検証するか、任意のコマンドに対し-Ztrackフラグを使用してP4LOGに書き込まれたはずの行を出力するとよいでしょう。例:

p4 -Zpeeking=1 -Ztrack sync

以上によって、11のデータベーステーブルの出力が生成されます。ここで重要な行は「locks read/write」を呼び出している行です。

...
--- db.counters
---   pages in+out+cached 3+0+2
---   locks read/write 1/0 rows get+pos+scan put+del 1+0+0 0+0
--- db.user
---   pages in+out+cached 3+0+2
---   locks read/write 1/0 rows get+pos+scan put+del 1+0+0 0+0
...

(「locks read/write 1/0」)各テーブルのロック結果に現れている1は、1つのテーブルにつき1つの読み取り専用ロックがかかっていることを示しています。これに対して、

p4 -Zpeeking=2 -Ztrack sync

...
--- db.counters
---   pages in+out+cached 3+0+2
---   locks read/write 0/0 rows get+pos+scan put+del 1+0+0 0+0
...

からの診断出力は、db.countersで必要な読み取り専用ロックも書き込み専用ロックも行われることなく同期操作が完了したことを示しています。ピーキングを有効にしておくと、多数のコマンドでread/write 0/0ロックがかかっていること(あるいは少なくとも、ほとんどロックがかかっていなかったこと)がわかるでしょう。

単一のPerforceインスタンスは、db.peekingを意図せずオーバーライドする不適切な試行を検出し、無視します。そのような試行がテーブルロック方式を変更することによりデッドロックの危険を生むおそれがあるためです。(例えば、db.peekingに0を指定する(または値を指定せずにいる)ことでピーキングを無効にしているサーバに対し、db.peeking=3の使用を試行すると、サーバはその試行を完全に無視し、コマンドは古い方式で実行されます。)

以下のナレッジベース記事で説明している「サイドトラックサーバ」の場合、

http://answers.perforce.com/articles/KB_Article/Perforce-Metadata-Replication

このプロテクションは使用できません。

P4PORTに、サービスのホスト名ではなくサービスのIPアドレスを指定してみます。例えば、

P4PORT=host.domain:1666

とする代わりに、

P4PORT=1.2.3.4:1666

などと、サイト特定のIPアドレスとポート番号を指定してみてください。

大半のシステムでは、以下のコマンドを使用するとホストのIPアドレスを特定できます。

ping hostname

p4 infoがIPアドレスの使用時に即座に応答する一方で、ホスト名の使用時に即座に応答しない場合は、問題はDNSに関連している可能性があります。

Windows上でp4コマンドを使用すると、ある条件の下では応答時間の遅延が生じるおそれがあります。その条件とは、そのコマンドがディポシンタックスとワイルドカードの組み合わせから成るファイルパターンを使用していること、かつそのファイルパターンが引用符で囲まれていないことです。

p4 files //depot/*

以下のようにファイルパターンの前後を二重引用符で囲むことによって、遅延を防ぐことができます。

p4 files "//depot/*"

この問題の原因は、p4コマンドがWindowsのワイルドカード拡張機能を使用することにあります。二重引用符を使用しなければ、この機能は//depotをネットワーク接続されたコンピュータのパスとして解釈するので、depotというマシンの検索のために時間をむだに使ってしまうことになります。

Windowsでは、%SystemRoot%\system32\drivers\etc\hostsファイルを使用して、IPアドレスホスト名のホスト名の組み合わせをハードコード化することができます。このファイルへのエントリを追加することによって、DNSの問題を回避することができます。これに対応するUNIXファイルは、/etc/hostsです。

以上の原因追究の手順をすべて試しても応答時間の遅延の原因を明らかにできない場合は、p4の実行ファイルそのものが、きわめてパフォーマンスの低いネットワークファイルシステム上に存在している可能性があります。この可能性を確認するには、以下のコマンドを試行してください。

p4 -V

これは、ネットワークアクセスを試みずにただバージョン情報を出力するだけのコマンドです。応答が遅延する場合、問題はp4実行ファイルそのものへのネットワークアクセスにある可能性があります。ローカルのファイルシステムにp4のコピーを作成するかダウンロードすると、応答速度が向上するはずです。

ネットワーク上の個々の読み取りまたは書き込みを待機する接続時間に上限を設定するには、ネットワークエラーとして接続を切断するまでに待機する秒数を構成可能変数net.maxwaitに設定します。信頼性の低い接続状態で作業するユーザは、net.maxwaitをP4CONFIGファイル内で設定するか、-vnet.maxwait=tをコマンド単位で使用し、タイムアウトのまでの待機秒数をtに指定するとよいでしょう。

net.maxwaitをグローバルオプションである-rNと組み合わせて、ネットワークのタイムアウト時に再接続を試行する回数をNに指定すると便利です。例:

p4 -r3 -vnet.maxwait=60 sync

というコマンドは、ユーザのワークスペースの同期が中断された場合に、同期を3回まで再試行します。3回目に60秒間でタイムアウトすると、コマンドは失敗します。

タイムアウトして再試行されるコマンド(ネットワーク接続が出力行の途中で失われた場合など)の出力形式は保証されないため、標準入力から読み込みを行うコマンドに-rを使用するのは避けてください。例えば、以下は、標準入力からファイルのリストを読み込み、それをp4 addに送るコマンドです。このコマンドの動作の結果として、中途半端な名前のファイルをディポに追加する操作が試みられるおそれがあります。

find . -print | p4 -x - -r3 add

(例えば、信頼性が極めて低い接続状態でファイルを多数追加しなければならない状況で)このような現象を回避するには、以下のようなアプローチを検討してください。

find directoryname -type f -exec p4 -r5 -vmax.netwait=60 add {} \;

このコマンドは、directoryname内のすべてのファイル(-type f)を検出したうえで、個々のファイルに対して「p4 -r5 -vmax.netwait=60 add」コマンドを実行することでファイルを1つずつ追加します。

すべてのファイルが追加されたら、p4 changeを使用してチェンジリストにチェンジリスト番号を割り当て、番号付きチェンジリストを最小単位でサブミットします。

p4 -r5 -vmax.netwait=60 submit -c changenum

接続が中断されると、番号付きチェンジリストのサブミットは再試行されます。

以下の「ゆるく制限されている」ビューは、簡単に設定できますが、きわめて大規模なディポでは問題を引き起こすおそれがあります。

//depot/...        //workspace/...

以上のビューでは、ディポ全体がクライアントワークスペースへマッピングされていました。大半のユーザにとって、このビューは著しく「絞り込む」ことができます。例えば、以下のビューの範囲は、ディポの特定の領域に限定されています。

//depot/main/srv/devA/...          //workspace/main/srv/devA/...
//depot/main/drv/lport/...         //workspace/main/dvr/lport/...
//depot/rel2.0/srv/devA/bin/...    //workspace/rel2.0/srv/devA/bin/...
//depot/qa/s6test/dvr/...          //workspace/qa/s6test/dvr/...

クライアントビューについてはとくに言えることですが、ブランチビューやラベルビューもまた、ユーザにとって必要な作業を行うのに十分な範囲だけを表示するように設定する必要があります。

クライアント、ブランチ、ラベルビューは、Perforce管理者または個々のユーザがそれぞれp4 client、p4 branch、p4 labelコマンドを使用することにより、設定されます。

スクリプトを最適化する方法(ブランチビューを使用するおよび一時クライアントワークスペースの活用を参照)のうち2つは、同様のテクニックに基づいています。コマンドに使用できるビューのサイズを制限することにより、実行する必要のあるコマンドの数を減らすとともに、コマンドの実行に必要なリソースの消費量も減らします。

プロテクション(“Perforceの管理: 保護”を参照)は、もうひとつのタイプのPerforceビューです。プロテクションは、p4 protectコマンドで設定され、ユーザが実行するコマンドによって影響を受けるディポファイルを制御します。

ただしクライアントビュー、ブランチビュー、ラベルビューとは異なり、プロテクションによって使用されるビューは、Perforceスーパーユーザによってしか設定できません。(プロテクションは、ディポファイルに対する読み取り権限と書き込み権限も制御しますが、権限レベルそのものはサーバのパフォーマンスに影響しません。)Perforce内でプロテクションを割り当てることにより、たとえユーザが「ゆるく制限されている」クライアント仕様を使用している場合であっても、ユーザのビューのサイズを効果的に制限することができます。

プロテクションは、以下のように、ユーザにもグループにも割り当てることができます。例:

write     user       sam           *     //depot/admin/...
write     group      rocketdev     *     //depot/rocket/main/...
write     group      rocketrel2    *     //depot/rocket/rel2.0/...

Perforceグループは、スーパーユーザがp4 groupコマンドを使用することにより、作成されます。Perforceグループによって、プロテクションの割り当てが簡単になるだけではなく、次のセクションで説明するように、maxresultsおよびmaxscanrowsによって便利なエラー防止メカニズムが使用できます。

各Perforceグループには、相互に関連するmaxresults、maxscanrows、maxlocktimeという値があります。それぞれデフォルトでは、unset(無制限)に設定されていますが、スーパーユーザは、p4 groupコマンドを用いて特定グループに対してこれらの値を制限することができます。

MaxResultsは、コマンド実行中にバッファリングされるデータの量を制限することにより、サーバがメモリを過剰に使用しないようにします。制限されたグループのユーザは、そのグループのMaxResultsの制限値より多くデータベース行をバッファリングするようなコマンドを実行することはできません。(ほとんどのサイトでは、MaxResultsを各ユーザのクライアントワークスペースで想定されるファイルの最大数よりも大きく設定する必要があります。)

MaxResultsと同様に、MaxScanRowsもサーバへ過度の要求がなされるような特定のユーザコマンドを制限します。(通常、一回の操作でスキャンされる行の数は、ディポ内のファイルの平均リビジョン数をMaxResultsに積算した数とほぼ等しくなっています。)

最後に、ある種のコマンドがデータベースを長期間にわたってロックし続けないようにするためには、MaxLockTimeを使用します。ミリ秒単位の数値でMaxLockTimeを設定し、データベースのロックを許容する最大時間を指定します。

これらの制限を設定するには、p4 groupのフォーム内の当該フィールドに数値を入力します。1人のユーザが複数のグループに登録されている場合、それらのグループのMaxResults(またはMaxScanRowsもしくはMaxLockTime)制限値の最大値(unlimitedを含むがデフォルトのunset設定を除く最大値)がそのユーザのMaxResults(またはMaxScanRowsもしくはMaxLockTime)値とみなされます。

Group:        rocketdev
MaxResults:   20000
MaxScanRows:  100000
MaxLockTime:  30000
Timeout:      43200
Subgroups:
Owners:
Users:
        bill
        ruth
        sandy

特定のグループについて、結果として処理される行数(またはスキャンされるデータベースの行数、もしくはデータベースロック時間を示すミリ秒)の制限を解除するには、そのグループのMaxResults、MaxScanRows、またはMaxLockTimeの値をunlimitedに設定します。

これらの制限はユーザに不便を強いることになる可能性があるため、特定の操作がサーバの動作を遅くしているのでない限りは使用しないでください。Perforceアプリケーションの中には大規模な処理を行うものもあるため、通例MaxResultsの値を10,000より小さくすることはありません。また、MaxScanRowsは50,000より小さくせず、MaxLockTimeの値は1,000から30,000(1秒から30秒)の範囲内に設定します。

各Perforceコマンドで影響を受けるファイル数などの詳細については、コマンドラインで以下を実行してください。

監視機能が有効(p4 configure set monitor=1またはそれ以上)の場合、構成可能変数server.maxcommandsを設定して、サービスが同時に処理できるコマンド要求の数を制限できます。

理想的には、この値は、ベースとなるハードウェアリソースが過負荷になる前に暴走スクリプトやサービス不能を検出できる程度に十分低く設定すると同時に、平均接続数とサイトでのピーク処理量との間に十分なゆとりが保たれる程度に高く設定します。

P4LOGが設定されている場合、サーバログには次の形式の行が含まれます。

Server is now using nnn active threads.

サーバログで、サイトにおける通常時の処理量レベルを知ることができます。一般的には、server.maxcommandsはサイトでの予想される処理量のピークの200～500%以上に設定します。

時間を経るにつれ、Perforceサーバにはアクティブな開発モードでなくなった古いプロジェクトに関連するメタデータが蓄積されていきます。大規模なサイトでは、使用されるデータ群(特にdb.haveとdb.labelsテーブルに格納されたデータ)を減らすことにより、パフォーマンスを大幅に向上することができます。

Depot:       unload
Type:        unload
Map:         unloaded/...

Perforceのコマンドラインクライアントであるp4では、対話形式で実行可能なコマンドすべてをスクリプトにより実行できます。Perforceサーバは、ユーザのコマンド発行よりもはるかに速くコマンドを処理できるため、完全な対話形式の環境では、優れた応答時間が期待できます。ただし、例えばトリガ、レビューデーモン、コマンドラッパなどのスクリプトにより発行されたp4コマンドは、スクリプトの効率を考慮していないとパフォーマンス上の問題を引き起こすことがあります。これはp4コマンドが本来非効率的だからではありません。対話形式でユーザが実行したp4が、場合によっては繰り返し操作に適したものではないためです。

このセクションでは、よくある効率上の問題とその解決法をいくつか紹介します。

for i in `p4 diff2 path1/... path2/...`
do
    [process diff output]
done

for i in `p4 files path1/...`
do
    p4 diff2 path1/$i path2/$i
    [process diff output]
done

for components in header1 header2 header3
do
    p4 edit ${component}.h
done

for components in header1 header2 header3
do
    echo ${component}.h >> LISTFILE
done
p4 -x LISTFILE edit

Branch:        pathA-pathB
View:
        pathA/src/...      pathB/src/...
        pathA/tests/...    pathB/tests/...
        pathA/doc/...      pathB/doc/...

Client:        XY-temp
View:
        pathA/src/...      //XY-temp/pathA/src/...
        pathB/tests/...    //XY-temp/pathB/tests/...
        pathC/doc/...      //XY-temp/pathC/doc/...

デフォルトでは、binaryタイプのファイルのリビジョンは、Perforceサーバに保存される際に圧縮されます。.GIFや.JPG画像、.MPGや.AVIのメディアコンテンツ、.gzで圧縮されたファイルなどは、ファイルフォーマットの一部に圧縮を含みます。Perforceサーバでこのようなファイルを圧縮しようとすると、ディスク容量の節約がほとんどできない割に、サーバのCPUリソースを消費する結果となります。

これらのファイルタイプに対してサーバストレージでの圧縮を無効にするには、コマンドラインまたはp4 typemapテーブルを用いて、ファイルタイプにbinary+F(圧縮せずに「+F」、サーバへ格納するバイナリ)を指定します。

サンプルのタイプマップテーブルを含め、p4 typemapについての詳細は、p4 typemapでファイルタイプを定義するを参照してください。

Perforceサーバには、パフォーマンス改善のために変更可能な多くの構成可能変数があります。

p4 help configurablesを実行すると、構成可能変数の完全なリストを表示できます。