私の会社では、アトラシアンクルーシブルの試験を数か月間続けています。リポジトリが適切に機能している場合、ユーザーはツールについて非常に肯定的なフィードバックを提供しています。私が抱えている問題は、いくつかの異なるプロジェクトがあり、それぞれに独自のリポジトリがあり、それらのリポジトリの一部が非常に大きいということです。特に、1つのリポジトリには多数のブランチがあり、おそらくブランチごとに約9,000個のファイルがあります。Crucibleでそのリポジトリを参照すると、非常に遅くなります。
CrucibleはCentOS VMで実行されています。VMには4 GBのRAMがあり、私はCrucibleの最大値を3 GBに設定しました。そのうち、現在2 GBを使用しています。私はこれをアトラシアンのサポートチケットで取り上げ、次のことを提案しました。
特に、かなり大きなSVNリポジトリがあるため、Fisheyeがディスク上に大きなインデックスファイルを作成することに気付くでしょう。パフォーマンスを向上させるために、次のことを試してください。
- Fisheyeで使用可能なメモリを増やします。
- 外部データベースへの移行。
- 不要なファイルやディレクトリをインデックスから除外します。
私はある程度これらすべてのものを試しましたが、これまでのところ、大きな助けにはなっていません。私は元々、組み込みのHSQL DBを使用して2GBのRAMを搭載したWindowsボックスでCrucibleを実行していました。CentOSでMySQLに移行すると、一部のリポジトリのパフォーマンスが向上し、Crucibleがはるかに安定しましたが、最大のリポジトリではあまり役に立たないようでした。ツールの有用性を維持しながら、索引付けから除外できるファイル/ブランチは非常に多くあります。
そうだとしたら、めちゃくちゃ強力なハードウェアに投資することなく、大規模なリポジトリでCrucibleを高速化する方法についてのヒントはありますか？
ありがとう！
編集：私は、明示的に上記のことを言及しなかった私がいるので、明確にするのです FishEyeのを使用。
編集2：最初にこれを投稿して以来、パフォーマンスは新しいCrucibleリリースで多少改善されましたが、それでも決して素晴らしいとは言えません。この問題は、私たちが使用しているよりもはるかに強力なハードウェアを備えているユーザーを含め、多くのユーザーに影響を及ぼしているようです。したがって、それはハードウェアの問題ではなく、Crucibleに固有の非効率性の問題であると私は考えています。アトラシアンはこの問題を認識しており、今後のリリースでさらにパフォーマンスが改善される予定です。そのため、これらの変更により問題が解決されることを願っています。
編集3：いつまでこの質問をしたかを忘れていたので、以前の編集では、最初に質問されたときからハードウェアの状況も変化したことについては触れませんでした。現在、専用の物理サーバーでCrucibleを実行していますが、CentOSを使用しています。ハードウェアはまだ控えめです（4GB RAM、クアッドコアCPU、および外部バックアップを備えたRAID 1のデュアル500GBディスク）が、VMから移動したときにパフォーマンスがわずかに向上しました。