SVN Leistung nach vielen Revisionen

Question

Ihr Projekt derzeit mit einem SVN-Repository, das mehrere hundert neue Revisionen pro Tag gewinnt. Das Repository befindet sich auf einem Win2k3-Server und wird über Apache / mod_dav_svn serviert.

Ich fürchte jetzt, dass die Leistung im Laufe der Zeit aufgrund zu viele Überarbeitungen abbaut.
Ist diese Angst vernünftig?
Wir planen bereits auf 1,5 zu aktualisieren, so in einem Verzeichnis Tausende von Dateien, die kein Problem auf lange Sicht sein.

  

Subversion auf speichert die Delta (Differenzen) zwischen zwei Revisionen, so hilft dies viel Platz sparend, besonders wenn Sie verpflichten Code (Text) und keine Binärdateien (Bilder und Dokumente).

Bedeutet dies, dass die Revision zu prüfen, 10 der Datei foo.baz um, SVN-Revision 1 nehmen und dann gilt die Deltas 2-10?

Answer 1

Welche Art von Repo haben Sie? FSFS oder BDB?

(Lassen Sie uns FSFS jetzt annehmen, denn das ist die Standardeinstellung ist).

Im Fall von FSFS wird jede Revision als diff gegen die vorherigen gespeichert. Also, würden Sie denken, dass ja, nach vielen Revisionen, es wäre sehr langsam sein.

Dies ist jedoch nicht der Fall. FSFS verwendet, was „überspringt Delta“ genannt werden, zu vermeiden, dass zu viele Lookups auf vorherige Umdrehungen zu tun.

(Wenn Sie also ein FSFS Repo verwenden, Antwort Brad Wilson ist falsch.)

Im Fall eines BDB Repo, die HEAD (letzte) Revision ist Volltext, aber die früheren Versionen werden als eine Reihe von Diffs gegen den Kopf gebaut. Dies bedeutet, dass die vorherigen Umdrehungen müssen neu berechnet werden nach jedem Commit.

Für weitere Informationen: http: //svn.apache. org / repos / asf / subversion / trunk / note / skip-Deltas

P. S. Unsere Repo ist etwa 20 GB, mit etwa 35.000 Revisionen, und wir haben keine Leistungsverschlechterung bemerkt.

Answer 2

Subversion speichert die aktuelle Version als Volltext, mit rückwärtsgewandten diffs. Dies bedeutet, dass Updates zu Kopf ist immer schnell, und was Sie inkrementell zahlen sucht weiter und weiter zurück in der Geschichte.

Answer 3

Ich habe persönlich nicht mit Subversion-Repositorys mit Codebases größer als 80K LOC für das aktuelle Projekt behandelt. Das größte Repository Ich habe eigentlich hatte etwa 1,2 Gigs, aber diese enthalten alle Bibliotheken und Dienstprogramme, die das Projekt verwendet.

Ich glaube nicht, der Tag zu Tag Nutzung wird so viel betroffen sein, aber alles, was durch die verschiedenen Versionen zu suchen braucht vielleicht ein bisschen langsamer. Es kann nicht einmal wahrnehmbar sein.

Nun, von einer System-Administrator Sicht gibt es ein paar Dinge, die Sie Performance-Engpässe minimieren helfen. Da Subversion ist meist ein dateibasiertes System, können Sie dies tun:

• Legen Sie die tatsächlichen Repositories in einem anderen Laufwerk
• Stellen Sie sicher, dass keine Datei-Anwendungen, die nicht svn Sperren arbeiten auf dem Laufwerk oben
• Stellen Sie die Laufwerke mindestens 7.500 RPM. Sie könnten versuchen, 10.000 RPM bekommen, aber es kann zu viel des Guten
• Aktualisieren Sie die LAN Gigabit, wenn alle im selben Büro ist.

Dies kann für Ihre Situation zu viel des Guten, aber das ist, was ich in der Regel für andere Dateiintensive Anwendungen gemacht haben.

Wenn Sie jemals „entwachsen“ Subversion, dann Perforce wird der nächste Schritt nach oben sein. Es ist mit Abstand des schnellsten Source-Control-App für sehr große Projekte.

Answer 4

Wir laufen einen Subversion-Server mit Gigabyte im Wert von Code und Binärdateien, und es ist bis zu mehr als zwanzigtausend Revisionen. Keine Verlangsamungen noch.

Answer 5

Subversion speichert nur die Delta (Differenzen) zwischen zwei Revisionen, so dass dies hilft viel Platz sparend, besonders, wenn Sie nur Code (Text) und keine Binärdateien (Bilder und Dokumente) begehen.

Zusätzlich Ive eine Menge sehr große Projekte gesehen svn und beklagte sich nie über die Leistung.

Vielleicht sind Sie über Kasse mal besorgt? dann denke ich, das ist wirklich ein Netzwerkproblem sein würde.

Oh, und Ive gearbeitet CVS-Repositories mit 2 GB + Sachen (Code, imgs, docs) und nie ein Leistungsproblem hatte. Da svn eine große Verbesserung auf cvs ist, ich glaube nicht, dass sollten Sie kümmern.

Hoffe, es hilft einfach Ihren Geist ein wenig;)

Answer 6

Ich glaube nicht, dass unsere Subversion durch Alterung verlangsamt. Wir haben derzeit mehrere Terabyte an Daten, meist binär. Wir Kasse / commit täglich bis zu 50 Gigabyte Daten. Insgesamt haben wir derzeit 50000 Revisionen. Wir verwenden FSFS als Speichertyp und Schnittstelle entweder direkt SVN: (Windows-Server) oder über Apache mod_dav_svn (Gentoo Linux Server)

.

Ich kann nicht bestätigen, dass dies zu Verlangsamung im Laufe der Zeit Svn wird, wie wir einen sauberen Server für Performance-Vergleich aufgebaut, die wir vergleichen können. Wir konnten keine signifikante Degradation messen.

Allerdings muß ich sagen, dass unsere Subversion standardmäßig ungewöhnlich langsam und offensichtlich ist es Subversion selbst, da wir mit einem anderen Computersystem versucht.

Aus unbekannten Gründen scheint Subversion komplett Server-CPU begrenzt. Unsere Kasse / commit Raten sind begrenzt auf zwischen 15-30 MegaBytes / s pro Client, da dann einem Server-CPU-Kern komplett aufgebraucht ist. Dies ist das gleiche für ein fast leeres Repository (1 GigaByte, 5 Versionen) wie für unsere vollständigen Server (~ 5 TeraByte, 50000 Versionen). Tuning wie Einstellung Kompression auf 0 = off hat das nicht verbessern.

Unsere hohe Bandbreite (liefert ~ 1 GigaByte / s) FC-Array im Leerlauf, die anderen Kerne im Leerlauf und Netzwerk (derzeit 1 GigaBit / s für Kunden, 10 Gigabit / s für Server) als auch im Leerlauf. Okay, nicht wirklich im Leerlauf, aber wenn nur 2-3% der verfügbaren Kapazität verwendet wird, nenne ich es im Leerlauf.

Es ist kein wirklicher Spaß alle Komponenten zu sehen, im Leerlauf, und wir müssen warten, für unsere Arbeitskopien erhalten ausgecheckt oder comitted. Im Prinzip habe ich keine Ahnung, was der Server-Prozess wird durch voll raubend einen CPU-Kern der ganze Zeit während der Prüfung zu tun / begehen.

Allerdings versuche ich nur einen Weg, um Melodie Subversion zu finden. Wenn dies nicht möglich ist, müssen wir vielleicht auf ein anderes System wechseln.

Deshalb: Antwort: Nr. SVN nicht abbaut in der Leistung ist es zunächst langsam

Natürlich, wenn Sie benötigen (hoch) keine Leistung, die Sie nicht ein Problem haben. Btw. all das oben Gesagte gilt 1.7 neueste stabile Version

subversioon

Answer 7

Die einzigen Operationen, die nach unten wahrscheinlich langsam sind Dinge, die Informationen aus mehreren Revisionen lesen (z SVN Schuld).

Answer 8

Ich bin nicht sicher ..... Ich benutze SVN mit Apache auf Centos 5.2. Funktioniert ok. Revisionsnummer war 8230 so ähnlich ... Und auf allen Client-Maschinen Commit war so langsam, dass wir mindestens 2min für eine Datei warten mussten, die 1 kb ist. Ich spreche von 1 Datei, die keine große Dateigröße hat.

Dann habe ich ein neues Repository. Gestartet von rev. 1. Funktioniert nun ok. Schnell. gebrauchte svnadmin xxxxxx erstellen. nicht überprüfen, ob es FSFS oder BDB .....

ist

Answer 9

Vielleicht sollten Sie überlegen, Ihren Workflow zu verbessern.

Ich weiß nicht, ob ein repos perf Probleme in diesen Bedingungen haben, aber Sie Fähigkeit, eine vernünftige Revision gehen wird.

In Ihrem Fall können Sie einen Validierungsprozess aufnehmen wollen, so ein Team begeht in einem Teamleiter Repo, und jeder von ihnen mit dem Team-Manager Repo, die die Nur-Lese-sauberen Firma repos begehen begehen. Sie haben eine saubere Auswahl an ihm Bühne machen, was nach oben verpflichten müssen.

Auf diese Weise kann jemand auf eine saubere Kopie, mit einer leicht zurückgehen Geschichte zu suchen. Merge sind viel einfacher, und Entwickler können immer noch ihre Verwirrung begehen so viel wie sie wollen.