クライアントワークスペースの増加によるdb.haveの肥大化への対処方法
最近、Helix Core Serverのパフォーマンスが低下しています。クライアントワークスペースの増加に伴う「db.have」の肥大化が疑われる場合、どのように確認し、対処すればよいですか。
「db.have」は、writeableタイプのクライアントワークスペースについて、最後に同期したファイルリビジョン（haveリスト）を管理するデータベースです。
クライアントワークスペース数や同期対象のファイル数が増えると、「db.have」のサイズやアクセス負荷が増加し、Helix Core Serverの処理性能に影響する場合があります。
ただし、「db.have」のサイズが大きいことだけで、パフォーマンス低下の原因とは断定できません。まずはデータベースのサイズや空きページの状況を確認し、不要なクライアントワークスペースが存在する場合は削除してください。
不要なクライアントワークスペースを削除した後も、データベースファイルのサイズや内部構造が問題となっている場合は、チェックポイントからデータベースを再構築することで改善する可能性があります。
「db.have」の役割
「db.have」には、各クライアントワークスペースが最後に同期したファイルリビジョンの情報が格納されます。この情報はhaveリストと呼ばれ、同期処理やファイルの状態確認などで使用されます。
デフォルトのwriteableタイプのクライアントワークスペースでは、複数のワークスペースのhaveリストが「db.have」で管理されます。そのため、多数のワークスペースから大量のファイルを同時に同期する環境では、「db.have」へのアクセスが競合し、パフォーマンスに影響する場合があります。
「db.have」の状態確認
データベーステーブルのサイズは、以下のコマンドで確認できます。
p4 dbstat -s
「db.have」のページ数、空きページ数、空き領域の割合は、以下のコマンドで確認できます。
p4 dbstat -f db.have
「p4 dbstat」はデータベースを走査するため、実行中にデータベースへの書き込み処理へ影響する可能性があります。利用者が少ない時間帯に実行することをご検討ください。
また、オペレーティングシステム上で、P4ROOT配下にある「db.have」のファイルサイズを確認することもできます。
ファイルサイズだけでは原因を特定できないため、P4LOG、サーバーのCPU使用率、メモリ使用量、ディスクI/Oなどの情報とあわせて確認してください。
不要なクライアントワークスペースの確認
ユーザの退職、端末の交換、プロジェクトの終了などにより、使用されていないクライアントワークスペースがサーバー上に残っている場合があります。
クライアントワークスペースの一覧は、以下のコマンドで確認できます。
p4 clients -a
削除する前に、対象のクライアントワークスペースについて、以下の点を確認してください。
- 利用されていないこと
- 編集中のファイルが残っていないこと
- 保留中のチェンジリストが不要であること
- 保留されたファイルが不要であること
- ビルド処理や自動化処理から使用されていないこと
不要なクライアントワークスペースの削除
通常のクライアントワークスペースは、以下のコマンドで削除できます。
p4 client -d <クライアントワークスペース名>
管理者が他のユーザのクライアントワークスペースを強制的に削除する場合は、以下のコマンドを使用できます。
p4 client -d -f <クライアントワークスペース名>
「-f」オプションを使用して削除すると、対象のクライアントワークスペースで開かれているファイルが取り消される場合があります。また、シェルフされたファイルが存在する場合は、追加のオプションが必要になることがあります。
強制削除は作業内容の消失につながる可能性があるため、対象ユーザおよび対象データを確認したうえで実行してください。
ユーザを削除する場合の注意事項
以下の「p4 user -d」コマンドでユーザを削除しても、そのユーザが所有していたクライアントワークスペースは削除されません。
p4 user -d -f <ユーザ名>
ユーザと、そのユーザが所有するクライアントワークスペースをまとめて削除する場合は、「p4 user -D」を使用できます。
最初に「-y」を付けずに実行し、削除対象を確認してください。
p4 user -D <ユーザ名>
表示された削除対象に問題がない場合は、「-y」を付けて削除を実行します。
p4 user -D -y <ユーザ名>
この操作は元に戻すことができません。
また、「p4 user -D」には、以下の制限があります。
- super権限が必要です
- エッジサーバー上では実行できません
- 保留されたファイルは削除されません
- P4 Code Reviewに関連付けられたクライアントワークスペースは削除されません
- 別のユーザがファイルを開いているクライアントワークスペースは、通常は削除されません
使用できるオプションや動作はHelix Core Serverのバージョンによって異なる場合があります。対象バージョンのコマンドリファレンスもあわせて確認してください。
データベースの再構築
Helix Core ServerのデータベースはB-tree構造で管理されています。長期間の運用や大量の追加・削除によって内部構造のバランスが崩れた場合、処理性能へ影響することがあります。
チェックポイントからデータベースを再作成すると、データベースのB-treeが再構成され、パフォーマンスやデータベースファイルのサイズが改善する可能性があります。
データベースを再構築する場合は、「db.have」だけを削除したり、個別に再作成したりしないでください。整合性を維持するため、必要なデータベース全体を、有効なチェックポイントおよびジャーナルから復元する必要があります。
再構築の手順は、ご利用の条件によって異なります。
誤った手順で作業すると、メタデータの消失やサーバー間の不整合につながる可能性があります。データベースの再構築を実施する場合、何かございましたら弊社サポートまでお問い合わせください。
再発防止
ビルド処理やCI処理などで、クライアントワークスペースの作成、同期、削除を頻繁に繰り返す場合は、用途に応じて以下のワークスペースタイプの利用を検討してください。
- readonly：同期や状態確認のみを行い、ファイルの編集やサブミットを行わない一時的なワークスペース
- partitioned：独立したhaveリストを使用し、編集やサブミットも行う一時的なワークスペース
- partitioned-jnl：独立したhaveリストを使用し、ジャーナルおよびチェックポイントによる復旧も必要なワークスペース
これらのタイプでは、「db.have」ではなく、クライアントワークスペースごとに独立したhaveリストを使用できるため、中央の「db.have」への競合を軽減できる場合があります。
利用には「client.readonly.dir」の設定が必要です。また、利用できるワークスペースタイプはHelix Core Serverのバージョンによって異なるため、導入前に対象バージョンのドキュメントをご確認ください。