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.

svn fisheye crucible

— Mitch Lindgren
quelle

Ich weiß, dass dies eine alte Frage ist, aber zu Ihrer Information für jeden, der dies über die Suche findet. In meiner (sehr begrenzten) jüngsten Erfahrung, wenn Sie die Datenbank nur auf eine externe PostgreSQL-Instanz verschieben, erhalten Sie eine große Beschleunigung für große Repos (dies setzt natürlich voraus, dass es sich um eine Maschine handelt ausreichend leistungsfähig, um eine Postgres-Instanz mit anständiger Größe auszuführen; ich habe auch die Vakuumeinstellungen für meine Hardware ein wenig angepasst, aber sofort war es schneller). Dies wird die Zugriffszeiten auf die Festplatte drastisch reduzieren und die Leistung und Benutzerfreundlichkeit ist weitaus besser als bei MySQL (oder zumindest für Fecru)

— Sam Whited,

Antworten:

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.

— Dave
quelle

Danke für die ausführliche Antwort. Ich habe meine ursprüngliche Frage aktualisiert, da ich vergessen habe, aktualisierte Hardwareinformationen in meine vorherige Bearbeitung aufzunehmen. Die Netzwerkgeschwindigkeit ist wahrscheinlich ein Problem bei der anfänglichen Indizierung, sollte jedoch keine Probleme verursachen, sobald die Indizes erstellt wurden (wo wir beim Durchsuchen indizierter Dateien große Schmerzen sehen). Am Ende haben wir Crucible in eine dedizierte physische Box und Säge verschoben eine bescheidene Leistungssteigerung. Die meisten unserer Entwickler verwenden Chrome, und ich habe alle, die Crucible verwenden, gewarnt, den IE NICHT als JavaScript-Engine zu verwenden (ohnehin vor IE9).

— Mitch Lindgren

Ich wusste nicht, dass zuvor angezeigte Dateien im Speicher gespeichert wurden, daher werde ich sicher jedem sagen, dass er aktualisiert werden soll, wenn die Dinge langsam werden. Zu Ihrer Information, Atlassian hat die Unterstützung für den Eclipse-Connector vollständig eingestellt, worüber ich viele Beschwerden bekam. Sie haben Anschlüsse für andere IDEs, aber Eclipse ist ein großer für uns. Einige unserer Teams verwenden Filialen nicht und andere ausgiebig. Die Teams, die keine Zweige verwenden, sind in Ordnung. Die Teams, die auf ernsthafte Langsamkeit stoßen. Leider kommt es nicht in Frage, sie zu bitten, ihren Prozess zu ändern.

— Mitch Lindgren

Ich habe mich zuvor mit der MySQL-Leistung befasst und werde dies erneut tun. Es sieht jedoch so aus, als würde der große Engpass nur die Indexdateien durchlaufen. Eine schnellere Festplatte könnte hier helfen, aber unsere Festplatten sind bereits ziemlich schnell (wenn auch nicht erstklassig. Bevor ich auf den neuen Server umgestiegen bin, habe ich viele E / A-Wartezeiten gesehen, aber ich sehe nicht mehr zu viel.), Denke ich Jetzt kann ich nur noch auf die von Atlassian angepriesenen Leistungsverbesserungen warten. Ich werde Ihre Antwort jedoch als akzeptiert markieren, da sie meiner Meinung nach viele wertvolle Informationen für andere enthält, die sich möglicherweise in derselben Situation befinden.

— Mitch Lindgren

> 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.

— Bill Weiss
quelle

Danke für die Information. Wir verwenden eine 64-Bit-JVM. Ich werde sehen, ob ich zu 32-Bit wechseln kann und ob es hilft. Bearbeiten: Ups - drücken Sie die Eingabetaste und es wurde mein Kommentar gespeichert, anstatt neue Zeilen hinzuzufügen. Mein Fehler. In Bezug auf Hardware ist dies ein Haken: Die Hardware-Situation liegt etwas außerhalb meiner Kontrolle, und es fällt mir schwer, höhere Ausgaben zu rechtfertigen, bis wir wissen, dass das Tool für alle Teams funktioniert, die es verwenden müssen. Ich werde sehen, ob das vorhandene Setup geändert werden kann (z. B. dieser VM mehr Speicher zuweisen).

— Mitch Lindgren

Entschuldigung für doppelte Kommentare, aber eine andere Frage: Sind Sie sicher, dass das Gedächtnis das Problem ist? Mir ist klar, dass 4 GB nicht viel sind, aber Fisheye / Crucible schöpfen nicht einmal das Maximum von 3 GB aus, das ich für die JVM festgelegt habe.

— Mitch Lindgren

Ich bin mir nicht sicher, ob das Ihr Problem ist, aber ich habe nur darauf hingewiesen, dass das nicht "wahnsinnig mächtig" ist. Könnten Sie bei schlechter Leistung einige Systemstatistiken sammeln? Lauf topund so weiter iostatund schau, was weh tut.

— Bill Weiss

"Wahnsinnig mächtig" war eine schlechte Wortwahl. Ich bin nur der Meinung, dass ein 4.000-Dollar-Server mit 48 GB RAM eine übermäßige Voraussetzung für eine Web-App ist, die von so wenigen Entwicklern verwendet wird.

— Mitch Lindgren

$ 4400/25 Benutzer / 2 Jahre == $ 88 / Entwickler / Jahr. Wie viele Entwicklungsstunden pro Jahr muss es Ihnen ersparen?

— Bill Weiss

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.

— Mark McDonald
quelle