fragen stichworte

Atlassian Tiegel sehr langsam auf großen Lager

Mein Unternehmen führt seit einigen Monaten einen Prozess gegen Atlassian Crucible durch. Für Repositorys, in denen es ordnungsgemäß funktioniert, haben Benutzer sehr positive Rückmeldungen zu dem Tool gegeben. Das Problem, das ich habe, ist, dass wir verschiedene Projekte haben, jedes mit einem eigenen Repository, und einige dieser Repositorys sind sehr groß. Insbesondere ein Repository hat eine große Anzahl von Niederlassungen und wahrscheinlich rund 9.000 Dateien pro Niederlassung. Das Durchsuchen dieses Repositorys in Crucible ist extrem langsam.

Der Crucible läuft auf einer CentOS-VM. Die VM verfügt über 4 GB RAM, und das Crucible-Maximum wurde auf 3 GB festgelegt, von denen derzeit 2 GB verwendet werden. Ich habe dies in einem Support-Ticket mit Atlassian angesprochen und sie haben Folgendes vorgeschlagen:

In particular because you have a rather large SVN repository you will likely find that Fisheye will be creating a large index file on disk. To help improve performance a few things you can try are:

Ich habe alle diese Dinge bis zu einem gewissen Grad ausprobiert, aber bisher hat nichts 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 auf CentOS verbesserte die Leistung einiger Repositorys und machte Crucible 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 der Nutzen des Tools erhalten bleibt.

Hat jemand deshalb Tipps, wie man Crucible in großen Repositories beschleunigen kann, ohne in wahnsinnig starke Hardware zu investieren?

Danke!

Bearbeiten: Um zu klären, da ich es oben nicht explizit erwähnt habe, verwende ich mit FishEye.

Edit 2: Seit ich das veröffentlicht habe, hat sich die Performance mit den neuen Crucible-Releases etwas verbessert, aber es ist auf keinen Fall großartig. Es hat den Anschein, dass dieses Problem viele Benutzer betrifft, darunter auch einige mit weitaus leistungsfähigerer Hardware, als wir verwenden. Daher glaube ich nicht, dass es sich um ein Hardwareproblem handelt, sondern um ein Problem mit einer ineffizienten Crucible-Ineffizienz. 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 ich diese Frage schon einmal gestellt hatte. In meinem letzten Schnitt habe ich vernachlässigt zu erwähnen, dass sich auch unsere Hardware-Situation seit der ursprünglichen Anfrage geändert hat. Wir führen Crucible jetzt auf einem dedizierten physischen Server aus und verwenden immer noch CentOS. Die Hardware ist immer noch bescheiden (4 GB RAM, Quad-Core-CPU und zwei 500-GB-Festplatten in RAID 1 mit externer Sicherung), wir haben jedoch eine leichte Leistungssteigerung festgestellt, als wir uns von der VM entfernt haben.

antworten

Da die Migration zu MySQL für einige Repositorys einen spürbaren Unterschied machte, sollten Sie die Datenbank für weitere Verbesserungen optimieren. Das Ändern einiger my.cnf -Werte von den Standardwerten kann einen großen Unterschied machen. Weitere Informationen finden Sie unter InnoDB Performance Optimization Basics. Suchen Sie auch nach langsamen Abfragen, indem Sie das langsame Abfrageprotokoll aktivieren, und fügen Sie gegebenenfalls Indizes hinzu.

Meine nächste Vermutung wäre die Netzwerkgeschwindigkeit: Befindet sich Ihre Crucible-Instanz in demselben kabelgebundenen lokalen Netzwerk wie Ihre SVN-Repositorys? Sie können auch versuchen, Crucible einen Testlauf auf derselben Maschine wie Ihr primäres Repository zu geben, um die Netzwerklatenz als Schuldigen auszuschalten.

Und ich weiß, dass es je nach Ihrer Arbeitsumgebung schwierig sein kann, aber das Ausführen von Crucible in einer VM ist wahrscheinlich nicht hilfreich. Atlassian notiert dies auf seiner sehr kurzen Seite Best Practices for Crucible Configuration. Ich bin mir sicher, dass Sie es schon gefunden haben, aber ich werde auch die Seite Tuning FishEye für andere Leser erwähnen.

Ich habe auch Leistungsprobleme bei großen Projekten, aber ich schreibe viel von der Langsamkeit auf Crucibles starkes Webinterface zurück. Dies gilt insbesondere, wenn Sie ein wenig herumklicken (zuvor angezeigte Seiten in einem Bericht bleiben im Browserfenster, auch wenn sie nicht sichtbar sind). Unsere Entwickler haben eine leichte Geschwindigkeitssteigerung durch den Wechsel zu Google Chrome festgestellt. Überprüfen Sie auch den Atlassian IDE Connector, ob für Ihre Entwicklungsumgebung ein kompatibles Plugin vorhanden ist. Der Eclipse IDE Connector hatte bei seiner letzten Verwendung (vor vielen Monaten) eigene Probleme, konnte jedoch zumindest große Dateisätze verarbeiten, ohne aufzulegen.

Abhängig von den Entwicklungspraktiken Ihres Unternehmens könnten Sie das Scannen einer großen Anzahl von Code-Zweigen beenden (vorausgesetzt, viele davon sind nicht mehr aktiv), und Repositorys für abgeschlossene/tote Projekte deaktivieren, bis sie benötigt werden. Mein Unternehmen verwendet sehr kleine Teams für eine große Anzahl von Projekten. Daher arbeiten wir meistens hauptsächlich an trunk, wodurch Zweige zur Ausnahme werden. Daher fügen wir explizit zu durchsuchende Zweige hinzu, anstatt alle Zweige standardmäßig einzuschließen. Stellen Sie außerdem sicher, dass Sie nicht versehentlich Tags scannen.

Wie ist Ihre CPU-Auslastung der Crucible-Box? Wenn Sie SVN hinter Apache HTTPD verwenden, prüfen Sie, wie viele Verbindungen Crucible während eines umfangreichen Repository-Scans beansprucht. Abgesehen davon bin ich nicht sicher, was Sie sonst noch anschauen könnten (vielleicht Festplattengeschwindigkeit? Repository-Scan-Frequenz?), Aber hoffentlich helfen die obigen Tipps ein wenig.

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

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

Obwohl ich das selbst nicht wirklich probiert habe, habe ich genau die gleichen Symptome wie du.

Ich überlege gerade, gespeicherte Diff-Informationen für die beanstandeten Repositories auszuschalten. Ich stellte die Frage auf Atlassians Q & A-Site und erhielt einen vielversprechenden Rat.

Mein Problem ist das gleiche - Indizierung ist nicht das Problem, es ist eine riesige Festplatte, die auf einem schlecht funktionierenden Festplatten-Array in einer VM läuft. Da ich die Festplatte derzeit nicht aktualisieren kann, muss ich einen anderen Weg finden. Der Beantworter in meinem obigen Beitrag sagt, dass das Entfernen von Diff-Informationen den Festplatten-Fußabdruck reduzieren würde auf Kosten von die Möglichkeit, nach hinzugefügten/entfernten Zeilen zu suchen. Er schlägt jedoch auch vor, dass die Geschwindigkeit beim Durchsuchen von Dateien mit langen Historien nicht beeinträchtigt wird.

Wenn jemand anderes diesen & amp; kann mit diesem Schalter Erfolg/Misserfolg melden, bitte hier kommentieren.

Oh, und ich betreibe 2.7.13 mit den gleichen Leistungsproblemen.