Performance-Einbruch bei SVN

[Murray]

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]

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]

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]

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.
Subversion ist Open Source Software, siehe http://subversion.tigris.org/
Dieses Proukt enthält von CollabNet entwickelte Software.
(http://www.Collab.Net/)

Die folgenden ZugriffsModule (ZM) für Projektarchive stehen zur Verfügung:

* ra_dav : Module for accessing a repository via WebDAV (DeltaV) protocol.
- behandelt 'http' Schema
- behandelt 'https' Schema
* ra_local : Module for accessing a repository on local disk.
- behandelt 'file' Schema
* ra_svn : Module for accessing a repository using the svn network protocol.
- behandelt 'svn' Schema

 

[Murray]

Kommandozeile: svn --version

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

svn, Version 1.1.4 (r13838)
³bersetzt Apr 5 2005, 06:17:07

Copyright (C) 2000-2004 CollabNet.
Subversion ist Open Source Software, siehe http://subversion.tigris.org/
Dieses Proukt enthõlt von CollabNet entwickelte Software.
(http://www.Collab.Net/)

Die folgenden ZugriffsModule (ZM) f³r Projektarchive stehen zur Verf³gung:

* ra_dav : Module for accessing a repository via WebDAV (DeltaV) protocol.
- behandelt 'http' Schema
- behandelt 'https' Schema
* ra_local : Module for accessing a repository on local disk.
- behandelt 'file' Schema
* ra_svn : Module for accessing a repository using the svn network protocol.
- behandelt 'svn' Schema

 

[kama]

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]

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]

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]

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: