大規模なリポジトリでAtlassianCrucibleが非常に遅い
私の会社は、AtlassianCrucibleのトライアルを数か月間実行しています。リポジトリが適切に機能している場合、ユーザーはツールについて非常に肯定的なフィードバックを提供しています。私が抱えている問題は、それぞれが独自のリポジトリを持ついくつかの異なるプロジェクトがあり、それらのリポジトリのいくつかは非常に大きいということです。特に1つのリポジトリには多数のブランチがあり、ブランチごとに約9,000個のファイルがあります。 Crucibleでそのリポジトリを参照するのは非常に時間がかかります。
CrucibleはCentOS VMで実行されています。 VMには4GBのRAMがあり、Crucibleの最大値を3GBに設定しましたが、現在2GBを使用しています。これをAtlassianのサポートチケットで提示しました。以下：
特に、かなり大きなSVNリポジトリがあるため、Fisheyeがディスク上に大きなインデックスファイルを作成していることに気付くでしょう。パフォーマンスを向上させるために、次のことを試してください。
- Fisheyeで利用可能なメモリを増やす。
- 外部データベースへの移行 。
- 不要なファイルとディレクトリをインデックスから除外します 。
私はこれらすべてのことをある程度試しましたが、これまでのところ、大きな助けにはなりませんでした。私はもともと、組み込みのHSQL DBを使用して2GBのRAMのWindowsボックスでCrucibleを実行していました。CentOSでMySQLに移行すると、一部のリポジトリのパフォーマンスが向上し、Crucibleがはるかに安定しましたが、ツールの有用性を維持しながら、インデックスから除外できるファイルやブランチは非常に多くあります。
そういうわけで、めちゃくちゃ強力なハードウェアに投資せずに、大規模なリポジトリでCrucibleを高速化する方法について誰かがヒントを持っていますか？
ありがとう！
編集：明確にするために、上記で明示的に言及しなかったので、FishEyeを使用してamします。
編集2：元々これを投稿していたため、新しいCrucibleリリースでパフォーマンスが多少向上しましたが、それでも決して素晴らしいとは言えません。この問題は 多くのユーザーに影響を与えます のようです。これには、私たちが使用しているものよりもはるかに強力なハードウェアを備えたものも含まれます。したがって、ハードウェアの問題ではなく、Crucibleに固有の非効率性の問題であると私は考えています。アトラシアンはこの問題を認識しており、今後のリリースではさらにパフォーマンスの改善が含まれる予定です。そのため、これらの変更により問題が解決されることを願っています。
編集3：この質問をしたのはどれくらい前か忘れていたので、前回の編集では、ハードウェアの状況についても言及していませんでした。最初に尋ねられてから変更されました。現在、CentOSを使用したまま、専用の物理サーバーでCrucibleを実行しています。ハードウェアはまだ控えめですが（外部バックアップを備えたRAID 1の4GB RAM、クアッドコアCPU、デュアル500GBディスク）、VMから離れるとパフォーマンスがわずかに向上しました。
MySQLに移行すると、一部のリポジトリで顕著な違いが生じたため、データベースを調整してさらに改善することを検討してください。いくつかの変更my.cnfデフォルトの値は、大きな違いを生む可能性があります。詳細については、 InnoDB Performance Optimization Basics を参照してください。 slow query log を有効にしてスロークエリをチェックし、必要に応じてインデックスを追加します。
次の推測はネットワーク速度です。CrucibleインスタンスはSVNリポジトリと同じ有線ローカルネットワーク上にありますか？可能であれば、Crucibleをプライマリリポジトリと同じマシンで試用して、ネットワークの遅延を原因として排除することもできます。
作業環境によっては難しいかもしれませんが、CrucibleをVMで実行しても、おそらく役に立たないでしょう。Atlassianは、非常に簡単にこれを記録しています ベストCrucible Configurationのプラクティス ページ。すでにご覧になっていると思いますが、他の読者向けの Tuning FishEye ページについても説明します。
大規模なプロジェクトでもパフォーマンスの問題がありますが、速度が遅いのはCrucibleの重いWebインターフェイスが原因です。これは、少しクリックした後は特に当てはまります（レビューで以前に表示されたページは、見えない場合でもブラウザウィンドウに残ります）。開発者は、GoogleChromeに切り替えることで速度がわずかに向上することに気づきました。また、開発環境に互換性のあるプラグインが存在する場合は Atlassian IDE Connector を確認してください。EclipseIDE Connectorには、私が最後に使用したとき（何ヶ月も前）に所有していましたが、少なくとも大きなファイルセットをハングアップすることなく処理できました。
会社の開発慣行によっては、多数のコードブランチのスキャンを停止し（それらの多くがアクティブでなくなったと想定）、必要になるまで完了/デッドプロジェクトのリポジトリを無効にすることができます。私の会社は非常に小さなチームを多数のプロジェクトで利用しているため、ほとんどの場合、主にtrunkに取り組んでおり、ブランチは例外です。したがって、デフォルトですべてのブランチを含めるのではなく、スキャンするブランチを明示的に追加します。また、誤ってタグをスキャンしていないことを確認してください。
CrucibleボックスのCPU使用率はどうですか？ Apache HTTPDの背後でSVNを使用している場合は、大きなリポジトリスキャン中にCrucibleによって消費される接続の数を調べます。それとは別に、他に何を調べればよいのかはわかりませんが（おそらくディスク速度？リポジトリスキャンの頻度？）、上記のヒントが少し役立つことを願っています。
> RAMは4 Gは「めちゃくちゃ強力な」ハードウェアではありません。25人のユーザーがいて、Fisheye（あなたが言及している）を使用していると仮定すると、ソフトウェア。4万ドルで、48GのRAMを搭載したサーバーを購入できます。
また、64ビットJVMを使用していますか？ドキュメントは、32ビットJVMの方が（より少ないのと同様に）メモリフットプリントが改善されることを示唆しています。
私は実際にこれを試したことはありませんが、あなたとまったく同じ症状が発生しています。
現在、問題のあるリポジトリの保存された差分情報をオフにすることを検討しています。 AtlassianのQ＆Aサイト で質問し、いくつかの有望なアドバイスを得ました。
私の問題は同じです-インデックス作成は問題ではありません。それは、VMのパフォーマンスの低いディスクアレイで実行される巨大なディスクフットプリントです。現在、ディスクをアップグレードできないので、別の方法を見つける必要があります。上記の私の投稿の回答者は、差分情報を削除するとディスクフットプリントが減少犠牲になります追加/削除された行を検索する機能が失われると述べています。彼はまた、それが長い履歴を持つファイルを閲覧する速度に影響を及ぼさないだろうと示唆しています。
他の誰かがこれを見て、このスイッチの成功/失敗を報告できる場合は、ここにコメントしてください。
ああ、私は同じパフォーマンスの問題で2.7.13を実行しています。