# Performance-Einbruch bei SVN



## Murray (14. Jul 2006)

Problem: ein Subversion-Server, der seit etlichen Monaten von mehreren Benutzern verwendet wird und dabei mehrere tausend Files (jeweils zwischen wenigen Bytes bis zu mehreren KB groß) verwaltet, ist in den letzten Tagen schleichend langsamer geworden und mittlerweile überhaupt nicht mehr zu benutzen; die Clients warten endlos (zumindest, bis sie abgeschossen werden) auf Rückmeldung.

Am (Linux-)Server fällt nichts auf; CPU-Last und Speicherauslastung sehen gut aus; irgendwelche Systemfehlermeldungen, die z.B. auf Plattenprobleme hindeuten würden, gibt es nicht.

Hat hier jemand eine Idee, was da (schief-)läuft?


----------



## kama (14. Jul 2006)

Hi,

1. Welches OS genau? Linux?

2. Welche SVN Version

3. Welches Backend (FSFS oder BDB)?

In wie fern Performance einbußen? Vergleich?

Local auf dem Server selbst getestet?

4. Betrieb via Apache oder SVNServer?
    Konfiguration?

5. Zugriff der Clients
    per Command Line, TortoiseSVN oder Eclipse/IntelliJ etc.?

MfG
Karl Heinz Marbaise


----------



## Murray (14. Jul 2006)

1. Fedora-Linux
2. Wie finde ich das heraus?
3. BDB
4. SVNServer
5. primär Eclipse mit subclipse-Plugin, alternativ TortoiseSVN

Mit Performance-Einbruch meine ich, dass im Laufe eines Tages zunächst die Zeiten für irgendwelche Operationen mit dem SVN (synchronize,update,commit) immer länger wurden (absolute Zahlen habe ich nicht, aber das was, eigentlich mal in 2-3 Sekunden ging, dauerte dann mehrere Minuten). Heute morgen war dann überhaupt kein Arbeiten mehr möglich; synchronize auf ein kleines Modul (ca. 20 Java-Files) war nach einer halben Stunde immer noch nicht fertig.

Den Server haben wir schon neu gestartet, ohne dass das das Verhalten verändert hat.


----------



## AlArenal (14. Jul 2006)

Murray hat gesagt.:
			
		

> 2. Wie finde ich das heraus?



Kommandozeile:  svn --version

Dann kommt sowas wie:


> svn, Version 1.1.4 (r13838)
> übersetzt May 13 2005, 06:29:47
> 
> Copyright (C) 2000-2004 CollabNet.
> ...


----------



## Murray (14. Jul 2006)

AlArenal hat gesagt.:
			
		

> Kommandozeile:  svn --version


Danke, das hatte ich gesucht, aber bei "svn help" oder "svn -?" wird das unterschlagen.



			
				svn --version hat gesagt.:
			
		

> svn, Version 1.1.4 (r13838)
> ³bersetzt Apr  5 2005, 06:17:07
> 
> Copyright (C) 2000-2004 CollabNet.
> ...


----------



## kama (14. Jul 2006)

Hi,

welche Release des Eclipse PlugIns verwendet ihr? 0.9 oder schon 1.0.X?
Welce Release TortoiseSVN?

Vorschläge:

0. eventuelles Update Eclipse PlugIn (1. Vermutung)

1. Update auf neue Release mind. 1.2.3

2. Damit wird vom BDB auf FSFS backend umgestellt (default)

(3. Betrieb nicht per SVNServer sondern per Apache.)

4. Netzwerkverbindungen zu den Clients usw. Laufende Prozesse auf dem Linux Server untersuchen (Load-Verhalten)


MfG
Karl Heinz Marbaise


----------



## Murray (14. Jul 2006)

Subclipse = 1.0.1, TortoiseSVN = 1.2.6

Die Server-Last (laufende Prozese, CPU, Memory) ist unauffällig; auch das Netzwerk scheint nicht stärker belastet zu sein als sonst.

Könnte es sich lohnen, vor einem Update eine DB-Recovery (bevorzugt unter svnadmin recover, notfalls direkt mit db_recover) zu versuchen?


----------



## kama (14. Jul 2006)

Hi,

erster wichtigster Schritt per "svnadmin dump" ein Backup vom Repository machen und dann "recover".

Das sollte man auf jeden fall mal machen. Nach dem Recover ein "svnadmin verify"...

und dann auf 1.2.3 umsteigen.

PS.: Ich würde noch auf 1.0.3 vom Subclipse umsteigen...

MfG
Karl Heinz


----------



## Murray (14. Jul 2006)

OK, nach der Recovery geht es wieder (falls dies hier später mal jemand lesen sollte, der ein ähnliches Problem hat: "svnadmin recover" sollte man nicht als root ausführen, sondern als der Benutzer, der auch svnserver ausführt, sonst gibt es später Probleme mit den Schreibrechten; das steht auch in der FAQ)

Offenbar waren noch ein paar Transaktionen abgebrochen worden, daher gibt es beim Committen von als neu gekennzeichneten Files vom Server Fehlermeldungen ("Attempted to lock an already-locked dir"). Das sollte sich wohl von Tortoise aus per Clean-Up lösen lassen.

Auf jeden Fall schonmal Danke für die Hilfe  :toll:


----------

