Prestazioni SVN dopo molte revisioni

Question

Il mio progetto sta attualmente utilizzando un repository svn che guadagna diverse centinaia di nuove revisioni al giorno. Il repository risiede su un server Win2k3 ed è servito tramite Apache / mod_dav_svn.

Ora temo che nel tempo le prestazioni peggioreranno a causa di troppe revisioni.
Questa paura è ragionevole?
Stiamo già programmando di eseguire l'aggiornamento a 1.5, quindi avere migliaia di file in una directory non sarà un problema a lungo termine.

  

Subversion on memorizza il delta (differenze), tra 2 revisioni, quindi questo aiuta a risparmiare MOLTO spazio, specialmente se si commette solo codice (testo) e non binari (immagini e documenti).

Significa che per verificare la revisione 10 del file foo.baz, svn prenderà la revisione 1 e quindi applicherà i delta 2-10?

Answer 1

Che tipo di repository hai? FSFS o BDB?

(Supponiamo per ora FSFS, dato che è l'impostazione predefinita.)

Nel caso di FSFS, ogni revisione è memorizzata come diff rispetto alla precedente. Quindi, penseresti che sì, dopo molte revisioni, sarebbe molto lento.

Tuttavia, non è così. FSFS utilizza quelli che sono chiamati "skip delta". per evitare di dover fare troppe ricerche sui precedenti giri.

(Quindi, se si utilizza un repository FSFS, la risposta di Brad Wilson è sbagliata.)

Nel caso di un repository BDB, la revisione HEAD (più recente) è full-text, ma le revisioni precedenti sono costruite come una serie di differenze rispetto alla testa. Ciò significa che i giri precedenti devono essere ricalcolati dopo ogni commit.

Per maggiori informazioni: http: //svn.apache. org / repos / ASF / subversion / trunk / note / skip-delta

P.S. Il nostro repository è di circa 20 GB, con circa 35.000 revisioni e non abbiamo notato alcun peggioramento delle prestazioni.

Answer 2

Subversion memorizza la versione più recente come testo completo, con differenze all'indietro. Ciò significa che gli aggiornamenti di Head sono sempre veloci e ciò che si paga in modo incrementale è guardare sempre più indietro nella storia.

Answer 3

Personalmente non ho gestito i repository Subversion con codebase più grandi di 80K LOC per il progetto reale. Il più grande repository che ho avuto in realtà era di circa 1.2 concerti, ma questo includeva tutte le librerie e le utilità che il progetto utilizza.

Non penso che l'utilizzo quotidiano ne risentirà così tanto, ma tutto ciò che deve guardare attraverso le diverse revisioni potrebbe rallentare un po '. Potrebbe anche non essere evidente.

Ora, dal punto di vista dell'amministratore di sistema, ci sono alcune cose che possono aiutarti a ridurre al minimo i colli di bottiglia delle prestazioni. Poiché Subversion è principalmente un sistema basato su file, puoi farlo:

• Inserisci i repository effettivi in ??un'unità diversa
• Assicurati che nessuna app di blocco dei file, oltre a svn, funzioni sull'unità sopra
• Crea le unità almeno 7.500 RPM. Potresti provare a ottenere 10.000 RPM, ma potrebbe essere eccessivo
• Aggiorna la LAN a gigabit, se tutti sono nello stesso ufficio.

Questo potrebbe essere eccessivo per la tua situazione, ma è quello che di solito ho fatto per altre applicazioni ad uso intensivo di file.

Se mai " cresce troppo " Subversion, quindi Perforce sarà il tuo prossimo passo. È senza dubbio l'app di controllo del codice sorgente più veloce per progetti di grandi dimensioni.

Answer 4

Stiamo eseguendo un server di sovversione con gigabyte di codice e binari, ed è fino a oltre ventimila revisioni. Nessun rallentamento ancora.

Answer 5

Subversion memorizza solo il delta (differenze), tra 2 revisioni, quindi questo aiuta a risparmiare MOLTO spazio, specialmente se si commette solo codice (testo) e nessun binario (immagini e documenti).

Inoltre ho visto molti progetti molto grandi usando svn e non mi sono mai lamentato delle prestazioni.

Forse sei preoccupato per i tempi di checkout? allora suppongo che questo sarebbe davvero un problema di rete.

Oh, e ho lavorato su repository CVS con 2 GB + di materiale (codice, img, documenti) e non ho mai avuto problemi di prestazioni. Dal momento che svn è un grande miglioramento per i CV non credo che dovresti preoccuparti.

Spero che ti aiuti un po 'a calmare la mente;)

Answer 6

Non credo che la nostra sovversione abbia rallentato con l'invecchiamento. Al momento disponiamo di numerosi TeraByte di dati, principalmente binari. Effettuiamo il checkout / il commit giornaliero fino a 50 GigaByte di dati. In totale abbiamo attualmente 50000 revisioni. Stiamo usando FSFS come tipo di archiviazione e ci stiamo interfacciaendo direttamente con SVN: (server Windows) o tramite Apache mod_dav_svn (Gentoo Linux Server).

Non posso confermare che questo rallenti nel tempo svn, poiché abbiamo impostato un server pulito per il confronto delle prestazioni con cui potremmo confrontare. NON abbiamo potuto misurare una significativa degrazione.

Comunque devo dire che la nostra sovversione è insolitamente lenta per impostazione predefinita e ovviamente è la stessa sovversione come abbiamo provato con un altro sistema informatico.

Per alcuni motivi sconosciuti, sovversione sembra essere completamente limitata dalla CPU del server. Le nostre percentuali di checkout / commit sono limitate a tra 15-30 MegaByte / s per client perché un core della CPU del server è completamente esaurito. Questo è lo stesso per un repository quasi vuoto (1 GigaByte, 5 revisioni) come per il nostro server completo (~ 5 TeraByte, 50000 revisioni). L'ottimizzazione come l'impostazione della compressione su 0 = off non ha migliorato questo.

Anche il nostro Highbandwith (fornisce ~ 1 GigaByte / s) inattivo FC-Array, gli altri core inattivi e di rete (attualmente 1 GigaBit / s per client, 10 GigaBit / s per server). Va bene non al minimo ma se viene utilizzato solo il 2-3% della capacità disponibile, lo chiamo al minimo.

Non è davvero divertente vedere tutti i componenti inattivi e dobbiamo attendere che le nostre copie funzionanti vengano estratte o completate. Fondamentalmente non ho idea di cosa stia facendo il processo del server consumando completamente un core della CPU tutto il tempo durante il checkout / commit.

Comunque sto solo cercando di trovare un modo per ottimizzare la sovversione. Se ciò non fosse possibile, potrebbe essere necessario passare a un altro sistema.

Pertanto: risposta: nessun SVN non si degrada in termini di prestazioni, inizialmente è lento.

Ovviamente se non hai bisogno di prestazioni (elevate) non avrai problemi. Btw. tutto quanto sopra si applica all'ultima versione stabile del subversioon 1.7

Answer 7

Le uniche operazioni che possono rallentare sono le cose che leggono le informazioni da più revisioni (ad esempio SVN Blame).

Answer 8

Non sono sicuro ..... Sto usando SVN con apache su Centos 5.2. Funziona bene Il numero di revisione era 8230 qualcosa del genere ... E su tutte le macchine client Commit era così lento che abbiamo dovuto aspettare almeno 2 minuti per un file che è 1kb. Sto parlando di 1 file che non ha grandi dimensioni di file.

Quindi ho creato un nuovo repository. Iniziato dalla rev. 1. Ora funziona bene. Veloce. usato svnadmin creare xxxxxx. non ha verificato se si tratta di FSFS o BDB .....

Answer 9

Forse dovresti considerare di migliorare il tuo flusso di lavoro.

Non so se un repository avrà problemi perf in queste condizioni, ma la tua capacità di tornare a una revisione sana lo farà.

Nel tuo caso, potresti voler includere un processo di convalida, quindi un team si impegna in un repository di team leader e ciascuno di essi si impegna nel repository di team manager che si impegna nei repository puliti di sola lettura. In questa fase hai fatto una selezione chiara di quale commit deve andare in cima.

In questo modo, chiunque può tornare a una copia pulita, con una cronologia facile da consultare. L'unione è molto più semplice e gli sviluppatori possono ancora commettere il loro disordine quanto vogliono.