Atlassian Crucible molto lento su un grande repository


8

La mia azienda ha condotto una prova di Atlassian Crucible da alcuni mesi ormai. Per i repository in cui funziona correttamente, gli utenti hanno fornito un feedback molto positivo sullo strumento. Il problema che sto riscontrando è che abbiamo diversi progetti diversi, ognuno con un proprio repository e alcuni di questi repository sono molto grandi. Un repository in particolare ha un gran numero di filiali e probabilmente circa 9.000 file per filiale. La navigazione del repository in Crucible è estremamente lenta.

Crucible è in esecuzione su una VM CentOS. La VM ha 4 GB di RAM e ho impostato il massimo di Crucible a 3 GB, di cui attualmente utilizza 2 GB. L'ho menzionato in un ticket di supporto con Atlassian e mi hanno suggerito quanto segue:

In particolare perché hai un repository SVN piuttosto grande, probabilmente scoprirai che Fisheye creerà un file indice di grandi dimensioni su disco. Per migliorare le prestazioni, alcune cose che puoi provare sono:

Ho provato tutte queste cose fino a un certo punto, ma finora nessuna mi ha aiutato molto. Inizialmente stavo eseguendo Crucible su una scatola di Windows con 2 GB di RAM utilizzando il DB HSQL incorporato. Passare a MySQL su CentOS ha visto un aumento delle prestazioni per alcuni repository e ha reso Crucible molto più stabile, ma non sembrava essere di grande aiuto con il nostro repository più grande. Esistono solo molti file / rami che posso escludere dall'indicizzazione mantenendo l'utilità dello strumento.

Stando così le cose, qualcuno ha qualche consiglio su come velocizzare Crucible su grandi repository, senza investire in hardware follemente potente?

Grazie!

Modifica: per chiarire, dal momento che non l'ho menzionato esplicitamente sopra, sto usando FishEye.

Modifica 2: da quando ho pubblicato questo post, le prestazioni sono migliorate un po 'con le nuove versioni di Crucible, ma non è comunque eccezionale. Sembra che questo problema riguardi molti utenti , inclusi alcuni con hardware molto più potente di quello che stiamo utilizzando. Pertanto, non credo che sia un problema hardware, ma piuttosto un problema con inerente inefficienza in Crucible. Atlassian è a conoscenza del problema e includerà ulteriori miglioramenti delle prestazioni nelle versioni future, quindi speriamo che questi cambiamenti risolvano i nostri problemi.

Modifica 3: Avevo dimenticato quanto tempo fa avevo posto questa domanda, quindi nella mia precedente modifica ho trascurato di menzionare che anche la nostra situazione hardware è cambiata da quando era stata inizialmente posta. Ora stiamo eseguendo Crucible su un server fisico dedicato, utilizzando ancora CentOS. L'hardware è ancora modesto (4 GB di RAM, CPU quad core e doppi dischi da 500 GB in RAID 1 con backup esterno), ma abbiamo visto un leggero aumento delle prestazioni quando ci siamo allontanati dalla VM.


So che questa è una vecchia domanda, ma Cordiali saluti a chiunque lo trovi tramite la ricerca, nella mia (recente) esperienza (molto limitata), il semplice spostamento del database in un'istanza PostgreSQL esterna ti darà una grande accelerazione per repository di grandi dimensioni (ovviamente, presuppone che la macchina sia sufficientemente potente per eseguire un'istanza di Postgres di dimensioni decenti; ho anche modificato un po 'le impostazioni del vaccino per il mio hardware, ma appena pronto era più veloce). Ciò ridurrà drasticamente i tempi di accesso al disco, e le prestazioni e l'usabilità sono di gran lunga migliori di mysql (o almeno, sembra essere per fecru)
Sam Whited,

Risposte:


2

Poiché la migrazione a MySQL ha fatto una notevole differenza per alcuni repository, prendere in considerazione l'ottimizzazione del database per ulteriori miglioramenti. La modifica di alcuni my.cnfvalori dalle impostazioni predefinite può fare una differenza enorme. Vedi Nozioni di base sull'ottimizzazione delle prestazioni di InnoDB per ulteriori informazioni. Controlla anche le query lente abilitando il registro delle query lente e aggiungi gli indici dove appropriato.

La mia prossima ipotesi sarebbe la velocità della rete: la tua istanza Crucible è sulla stessa rete locale cablata dei tuoi repository SVN? Potresti anche provare a eseguire una versione di prova di Crucible sullo stesso computer del tuo repository primario, se possibile, per eliminare la latenza di rete come colpevole.

E so che potrebbe essere difficile a seconda dell'ambiente di lavoro, ma l'esecuzione di Crucible in una VM probabilmente non aiuta le cose; Atlassian ne prende nota nella loro brevissima pagina Best Practices for Crucible Configuration . Sono sicuro che l'hai già trovato, ma citerò anche la pagina Tuning FishEye per altri lettori.

Ho anche problemi di prestazioni per grandi progetti, ma attribuisco molta lentezza alla pesante interfaccia web di Crucible. Ciò è particolarmente vero dopo aver fatto clic per un po '(le pagine precedentemente visualizzate in una recensione rimangono nella finestra del browser, anche se nascoste alla vista). I nostri sviluppatori hanno notato un leggero aumento della velocità passando a Google Chrome. Controlla anche il connettore IDE Atlassian se esiste un plug-in compatibile per il tuo ambiente di sviluppo. Il connettore IDE di Eclipse ha avuto problemi propri l'ultima volta che l'ho usato (molti mesi fa), ma poteva almeno gestire set di file di grandi dimensioni senza riagganciare.

A seconda delle pratiche di sviluppo della tua azienda, potresti interrompere la scansione di un gran numero di rami di codice (supponendo che molti di essi non siano più attivi) e disabilitare i repository per progetti completati / morti fino a quando non sono necessari. La mia azienda utilizza team molto piccoli su un gran numero di progetti, quindi il più delle volte lavoriamo principalmente trunk, facendo delle filiali un'eccezione; pertanto aggiungiamo esplicitamente i rami da scansionare anziché includere tutti i rami per impostazione predefinita. Assicurati inoltre di non eseguire la scansione accidentale dei tag.

Come viene utilizzato la tua CPU sulla scatola Crucible? Se stai usando SVN dietro Apache HTTPD, esamina quante connessioni vengono consumate da Crucible durante una grande scansione del repository. A parte questo, non sono sicuro di cos'altro potresti guardare (forse la velocità del disco? Frequenza di scansione del repository?), Ma spero che i suggerimenti sopra ti aiuteranno un po '.


Grazie per la risposta dettagliata. Ho aggiornato la mia domanda originale poiché ho dimenticato di includere le informazioni hardware aggiornate nella mia modifica precedente. La velocità della rete è probabilmente un problema nell'indicizzazione iniziale ma non dovrebbe causare problemi una volta creati gli indici (che è dove vediamo molto dolore - durante la navigazione dei file indicizzati.) Abbiamo finito per spostare Crucible in una scatola fisica dedicata e abbiamo visto un modesto aumento delle prestazioni. La maggior parte dei nostri sviluppatori usa Chrome e ho avvertito tutti quelli che usano Crucible NOT di usare IE come motore JavaScript (prima di IE9 comunque) è molto lento.
Mitch Lindgren,

Non sapevo che i file visualizzati in precedenza fossero mantenuti in memoria, quindi sarò sicuro di dire a tutti di aggiornare quando le cose rallentano. Cordiali saluti, tuttavia, Atlassian ha completamente abbandonato il supporto per il connettore Eclipse, di cui ho ricevuto molte lamentele. Hanno connettori per altri IDE ma Eclipse è un grande per noi. Per quanto riguarda le filiali, alcuni dei nostri team non li usano e alcuni lo fanno ampiamente. Le squadre che non usano i rami vanno bene. Le squadre che incontrano seri rallentamenti. Sfortunatamente chiedere loro di cambiare il loro processo è in qualche modo fuori discussione.
Mitch Lindgren,

Ho già esaminato le prestazioni di MySQL in precedenza e lo farò di nuovo. Sembra però che il grosso collo di bottiglia stia attraversando solo i file di indice. Un disco più veloce potrebbe aiutare qui, ma i nostri dischi sono già abbastanza veloci (anche se non in cima alla linea. Prima di passare al nuovo server ho visto un sacco di IO aspettare, ma non vedo più troppo.) Penso tutto quello che posso fare ora è aspettare i miglioramenti delle prestazioni pubblicizzate di Atlassian. Contrassegnerò la tua risposta come accettata, però, poiché penso che contenga molte informazioni preziose per gli altri che potrebbero trovarsi nella stessa situazione.
Mitch Lindgren,

1

> 4 G di RAM non sono hardware "follemente potenti". Supponendo che tu abbia 25 utenti e stai usando Fisheye (di cui parli), stai spendendo $ 4400 solo per il software. $ 4k su Dell potrebbero offrirti un server con 48G di RAM.

Inoltre, stai usando una JVM a 64 bit? I documenti suggeriscono che vedrai un migliore footprint di memoria (come in, meno di esso) su una JVM a 32 bit.


Grazie per le informazioni. Stiamo utilizzando una JVM a 64 bit. Vedrò se posso passare a 32 bit e vedere se aiuta. Modifica: Oops - premi invio e ha salvato il mio commento invece di aggiungere nuove righe. Colpa mia. Per quanto riguarda l'hardware, è una sorta di catch-22: la situazione hardware è in qualche modo fuori dal mio controllo, ed è difficile per me giustificare un aumento delle spese fino a quando non sappiamo che lo strumento funzionerà per tutti i team che hanno bisogno di usarlo. Vedrò se è possibile fare qualcosa alla configurazione esistente (ad esempio, assegnare più memoria a quella VM).
Mitch Lindgren,

Ci scusiamo per il doppio commento, ma un'altra domanda: sei sicuro che il problema sia la memoria? Mi rendo conto che 4 GB non sono molti, ma Fisheye / Crucible non stanno nemmeno raggiungendo il massimo di 3 GB che ho impostato sulla JVM.
Mitch Lindgren,

Non sono sicuro se questo sia il tuo problema, ma stavo solo sottolineando che non è "follemente potente". Mentre le prestazioni sono scarse, potresti raccogliere alcune statistiche di sistema? Corri top, iostate quant'altro, e vedi cosa fa male.
Bill Weiss,

"Follemente potente" era una cattiva scelta di parole. Sento solo che un server da $ 4.000 con 48 GB di RAM è un requisito fondamentale per un'app Web utilizzata da così pochi sviluppatori.
Mitch Lindgren,

3
$ 4400/25 utenti / 2 anni == $ 88 / dev / anno. Quante ore di sviluppo all'anno deve salvarti?
Bill Weiss,

0

Anche se non l'ho provato da solo, sto sperimentando esattamente gli stessi sintomi di te.

Attualmente sto pensando di disattivare le informazioni diff memorizzate per i repository offensivi. Ho posto la domanda sul sito di domande e risposte di Atlassian e ho ricevuto alcuni consigli promettenti.

Il mio problema è lo stesso: l'indicizzazione non è il problema, è un'enorme impronta del disco in esecuzione su un array di dischi con prestazioni scarse in una macchina virtuale. Dato che al momento non riesco ad aggiornare il disco, devo trovare un altro modo per aggirarlo. Il risponditore nel mio post sopra dice che la rimozione delle informazioni diff ridurrà l'impronta del disco a spese della perdita della capacità di cercare le linee aggiunte / rimosse . Anche se suggerisce anche che non influenzerà la velocità di navigazione dei file con una lunga storia.

Se qualcun altro lo vede e può segnalare il successo / fallimento con questo interruttore, si prega di commentare qui.

Oh, sto eseguendo la 2.7.13 con gli stessi problemi di prestazioni.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.