ファイルシステム

ここでは、ファイルサイズとディスクのI/Oを主に取り扱います。詳細については、「ファイルシステム」を参照してください。

ファイルシステムのパフォーマンス

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

Helixサーバが特定のハードウェア構成やファイルシステムを推奨することはありません。Linuxの非同期ディレクトリ更新の性質のため、Linuxサーバが最高のパフォーマンスを発揮する傾向があります。ただしLinuxサーバは、電源が切れるタイミングが悪いと、復旧が困難になる場合があります。

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

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

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

サーバルートとジャーナルの物理ドライブを別にする

P4ROOTディレクトリ(つまり、データベースおよびバージョンファイルを格納しているディレクトリ)は、ジャーナルファイルとは別の物理ドライブに置くことを推奨します。

• ジャーナルを別のドライブに保存しておけば、たとえP4ROOTを含むドライブがディスク故障により破損したとしても、その影響が使用中のジャーナルファイルにおよぶことはありません。その場合、ジャーナルファイルを使用して、消失または損傷したメタデータをすべて復元することができます。
• 実行中のジャーナルをdb.*ファイルと別にすることで、パフォーマンスを改善できる場合もあります。

詳細については、「バックアップとリカバリ」および「ジャーナルとアーカイブの場所」を参照してください。