Atlassian Crucible sehr langsam auf großem Repository

Meine Firma führt seit einigen Monaten einen Test mit Atlassian Crucible durch. Für Repositorys, in denen es ordnungsgemäß funktioniert, haben Benutzer sehr positive Rückmeldungen zum Tool gegeben. Das Problem, das ich habe, ist, dass wir mehrere verschiedene Projekte haben, jedes mit einem eigenen Repository, und einige dieser Repositorys sind sehr groß. Insbesondere ein Repository hat eine große Anzahl von Zweigen und wahrscheinlich rund 9.000 Dateien pro Zweig. Das Durchsuchen dieses Repositorys in Crucible ist äußerst langsam.

Crucible läuft auf einer CentOS-VM. Die VM verfügt über 4 GB RAM, und ich habe das Maximum von Crucible auf 3 GB festgelegt, wovon derzeit 2 GB verwendet werden. Ich habe dies in einem Support-Ticket bei Atlassian erwähnt, und sie schlugen Folgendes vor:

Insbesondere weil Sie ein ziemlich großes SVN-Repository haben, werden Sie wahrscheinlich feststellen, dass Fisheye eine große Indexdatei auf der Festplatte erstellt. Um die Leistung zu verbessern, können Sie Folgendes ausprobieren:

• Erhöhen des verfügbaren Speichers für Fisheye.
• Migration zu einer externen Datenbank .
• Ausschließen von Dateien und Verzeichnissen aus Ihrem Index, die nicht benötigt werden .

Ich habe all diese Dinge bis zu einem gewissen Grad ausprobiert, aber bisher hat keiner sehr geholfen. Ich habe Crucible ursprünglich auf einer Windows-Box mit 2 GB RAM unter Verwendung der integrierten HSQL-Datenbank ausgeführt. Die Umstellung auf MySQL unter CentOS führte bei einigen Repositorys zu einer Leistungssteigerung und machte Crucible viel stabiler, schien jedoch bei unserem größten Repository nicht viel zu helfen. Es gibt nur so viele Dateien / Zweige, die ich von der Indizierung ausschließen kann, während die Nützlichkeit des Tools erhalten bleibt.

Hat jemand Tipps, wie Sie Crucible in großen Repositories beschleunigen können, ohne in wahnsinnig leistungsfähige Hardware zu investieren?

Vielen Dank!

Edit: Um zu klären, da ich es nicht ausdrücklich oben erwähnt, ich bin mit FishEye.

Edit 2: Seit ich dies ursprünglich gepostet habe, hat sich die Leistung mit neuen Crucible-Versionen etwas verbessert, aber es ist immer noch keineswegs großartig. Es scheint, dass dieses Problem viele Benutzer betrifft , darunter einige mit weitaus leistungsfähigerer Hardware als wir. Daher glaube ich nicht, dass es sich um ein Hardwareproblem handelt, sondern um ein Problem mit der inhärenten Ineffizienz von Crucible. Atlassian ist sich des Problems bewusst und wird in zukünftigen Versionen weitere Leistungsverbesserungen vornehmen. Hoffentlich lösen diese Änderungen unsere Probleme.

Edit 3: Ich hatte vergessen, wie lange es her ist, dass ich diese Frage gestellt habe. In meiner vorherigen Bearbeitung habe ich versäumt zu erwähnen, dass sich auch unsere Hardwaresituation geändert hat, seit sie ursprünglich gestellt wurde. Wir führen Crucible jetzt auf einem dedizierten physischen Server aus und verwenden weiterhin CentOS. Die Hardware ist immer noch bescheiden (4 GB RAM, Quad-Core-CPU und zwei 500-GB-Festplatten in RAID 1 mit externer Sicherung), aber wir haben eine leichte Leistungssteigerung festgestellt, als wir uns von der VM entfernt haben.

Da die Migration zu MySQL bei einigen Repositorys einen spürbaren Unterschied machte, sollten Sie die Datenbank für weitere Verbesserungen optimieren. Das Ändern einiger my.cnfWerte aus den Standardeinstellungen kann einen großen Unterschied machen. Siehe InnoDB Performance - Optimierung Grundlagen für weitere Informationen. Suchen Sie auch nach langsamen Abfragen, indem Sie das Protokoll für langsame Abfragen aktivieren und gegebenenfalls Indizes hinzufügen.

Meine nächste Vermutung wäre die Netzwerkgeschwindigkeit: Befindet sich Ihre Crucible-Instanz im selben verkabelten lokalen Netzwerk wie Ihre SVN-Repositorys? Sie können auch versuchen, Crucible nach Möglichkeit auf demselben Computer wie Ihr primäres Repository zu testen, um die Netzwerklatenz als Schuldigen zu beseitigen.

Und ich weiß, dass es abhängig von Ihrer Arbeitsumgebung schwierig sein kann, aber das Ausführen von Crucible in einer VM hilft wahrscheinlich nicht weiter. Atlassian notiert dies auf seiner sehr kurzen Seite Best Practices for Crucible Configuration . Ich bin mir sicher, dass Sie bereits darauf gestoßen sind , aber ich werde auch die Seite Tuning FishEye für andere Leser erwähnen .

Ich habe auch Leistungsprobleme bei großen Projekten, schreibe aber einen Großteil der Langsamkeit der umfangreichen Weboberfläche von Crucible zu. Dies gilt insbesondere nach einigem Klicken (zuvor angezeigte Seiten in einer Überprüfung bleiben im Browserfenster, auch wenn sie nicht sichtbar sind). Unsere Entwickler haben durch den Wechsel zu Google Chrome einen leichten Geschwindigkeitsanstieg festgestellt. Überprüfen Sie auch den Atlassian IDE Connector, wenn ein kompatibles Plugin für Ihre Entwicklungsumgebung vorhanden ist. Der Eclipse IDE Connector hatte bei der letzten Verwendung (vor vielen Monaten) eigene Probleme, konnte jedoch zumindest große Dateigruppen verarbeiten, ohne aufzulegen.

Abhängig von den Entwicklungspraktiken Ihres Unternehmens können Sie das Scannen einer großen Anzahl von Codezweigen beenden (vorausgesetzt, viele von ihnen sind nicht mehr aktiv) und Repositorys für abgeschlossene / tote Projekte deaktivieren, bis sie benötigt werden. Mein Unternehmen setzt sehr kleine Teams für eine große Anzahl von Projekten ein. Daher arbeiten wir die meiste Zeit hauptsächlich daran trunk, wobei Filialen die Ausnahme bilden. Wir fügen daher explizit Zweige zum Scannen hinzu, anstatt standardmäßig alle Zweige einzuschließen. Stellen Sie außerdem sicher, dass Sie Tags nicht versehentlich scannen.

Wie ist Ihre CPU-Auslastung auf der Crucible-Box? Wenn Sie SVN hinter Apache HTTPD verwenden, überprüfen Sie, wie viele Verbindungen Crucible während eines großen Repository-Scans verwendet. Abgesehen davon bin ich mir nicht sicher, was Sie sonst noch sehen könnten (vielleicht Festplattengeschwindigkeit? Repository-Scan-Häufigkeit?), Aber hoffentlich helfen die obigen Tipps ein bisschen.

> 4 G RAM sind keine "wahnsinnig leistungsstarke" Hardware. Angenommen, Sie haben 25 Benutzer und verwenden Fisheye (was Sie erwähnen), geben Sie 4400 US-Dollar nur für die Software aus. $ 4k bei Dell könnten Ihnen einen Server mit 48 GB RAM kaufen.

Verwenden Sie auch eine 64-Bit-JVM? Die Dokumente schlagen vor, dass Sie auf einer 32-Bit-JVM einen besseren Speicherbedarf (wie in weniger davon) sehen.

Obwohl ich das selbst nicht ausprobiert habe, habe ich genau die gleichen Symptome wie Sie.

Ich denke derzeit darüber nach, gespeicherte Diff-Informationen für die fehlerhaften Repositorys zu deaktivieren. Ich habe die Frage auf der Q & A-Website von Atlassian gestellt und einige vielversprechende Ratschläge erhalten.

Mein Problem ist das gleiche - die Indizierung ist nicht das Problem, sondern ein großer Speicherbedarf, der auf einem Festplattenarray mit schlechter Leistung in einer VM ausgeführt wird. Da ich die Festplatte derzeit nicht aktualisieren kann, muss ich einen anderen Weg finden, um sie zu umgehen. Der Antwortende in meinem obigen Beitrag sagt, dass das Entfernen von Diff-Informationen den Platzbedarf auf der Festplatte verringert, auf Kosten des Verlusts der Fähigkeit, hinzugefügte / entfernte Zeilen zu durchsuchen . Er schlägt jedoch auch vor, dass dies die Geschwindigkeit beim Durchsuchen von Dateien mit langem Verlauf nicht beeinflusst.

Wenn jemand anderes dies sieht und Erfolg / Misserfolg mit diesem Schalter melden kann, kommentieren Sie dies bitte hier.

Oh, und ich verwende 2.7.13 mit denselben Leistungsproblemen.