[svn] performance svn

[trinite_t]

Ik heb vandaag svn werkend gekregen, na boel gedoe toch eindelijk werkend gekregen ..
Het draait nu allemaal zoals ik het wil. Alleen heb ik nog een probleempje. De snelheid waarme svn commando's uitvooert (via svnserve) is extreeeeeem laag. (enkele minuten voor een update waaraan een karakter is veranderd ed.) Dit gebeurt als ik svn vanaf de client benader, maar ook als ik hem benader via

code:

$ svn checkout svn://localhost/

Zelfs

code:

$ svn info svn://localhost/

duurde enkele minuten
En dat terwijl m'n load averages op de server 0.00 zijn...

Ik kan er niet bij waarom het zo traag is.. iemand anders enig idee?
BTW, het is een getoo servertje

[smesjz]

je kan toch ook checkout doen vanaf /path/naar/svn/repo ? zonder tussenkomst van svnserve?
Gaat dat wel snel? Welke svn versie gebruik je?

[trinite_t]

svnserve --version

code:

svnserve, version 1.3.1 (r19032)
   compiled Jun  6 2006, 10:48:28
[...]
The following repository back-end (FS) modules are available:

* fs_fs : Module for working with a plain file (FSFS) repository.

svn is dezelfde versie... Het rare is dat hij het nu soms wel opeen heel snel doet...
Verder doet hij het als ik hem lokaal gebruik (dus met file:// ipv svn://) wel snel (lijkt het). Al met al nogal wazig...8)7

[tomato]

Ja, lijkt me absoluut een netwerk issue.

[ppl]

tomato schreef op dinsdag 06 juni 2006 @ 23:32:
Ja, lijkt me absoluut een netwerk issue.

Mwoah, als hij ook al zo traag is op de localhost lijkt me dat niet.

Het zou opzich niet zo lang moeten duren maar dat is geheel afhankelijk van hoe groot je repository is.
Ik heb voor het afstuderen ook een aardige repository en als ik die lokaal of via svn+ssh een checkout doe dan duurt dat ook even minimaal een minuut. Vooral via SSH is het traag.
Hoe groot is je repository en op welk revisienummer zit je? Heb je je repository al eens opgeschoond?

[Surfer]

misschien gaat ie wel een reverse dns lookup proberen te doen en kan hij je host niet resolven of heb je geen goede DNS servers ingesteld staan?

Ik heb ook wel eens onverklaarbare timeouts gehad, en dat lag ook aan een van de bovenstaande zaken (was niet met subversion, maar met sshd)

check voor de zekerheid je resolv.conf en je hosts file...

[trinite_t]

ppl schreef op woensdag 07 juni 2006 @ 00:44:
[...]
Het zou opzich niet zo lang moeten duren maar dat is geheel afhankelijk van hoe groot je repository is.
Ik heb voor het afstuderen ook een aardige repository en als ik die lokaal of via svn+ssh een checkout doe dan duurt dat ook even minimaal een minuut. Vooral via SSH is het traag.
Hoe groot is je repository en op welk revisienummer zit je? Heb je je repository al eens opgeschoond?

Mijn repository is nog maar klein.. ben nu vooral even aan het spelen met svn zodat ik er alles ff van door krijg... zit nu op rev.10 en de grootte is nu 7MB..

Verder zat er idd een foutje in m'n hosts file. Dit heb k nu gefixed.. alleen wordt het er niet sneller door...
Ik kon me er nog wat bij indenken als die repository te groot was, maar dan zou er volgens mij ook best wel wat activiteit van svnserve moeten plaatsvinden.. dit komt nu niet eens voor in de takenlijst van top. (gesorteerd op cpu gebruik).

Het lijkt er op dat het nu mis gaat bij het de authentication. De eerste keer dat ik inlog (als er dus nog geen gebruikersnaam en wachtwoord opgeslagen is) gaat het wel snel, de daarop volgende keren is het een kwestie van een heleboel geduld hebben... eenmaal ingelogd gaat het wel weer snel..
Toch niet... inloggen gaat juist wel snel, daarna hangt het voor eent tijdje. (test nu op een lege repository )

[ Voor 19% gewijzigd door trinite_t op 07-06-2006 11:21 ]

[tomato]

trinite_t schreef op woensdag 07 juni 2006 @ 08:48:
Mijn repository is nog maar klein.. ben nu vooral even aan het spelen met svn zodat ik er alles ff van door krijg... zit nu op rev.10 en de grootte is nu 7MB..

(Mijn repository is 19 MB (gzip 9.5 MB) maar met 1097 revisies )

Hoe dan ook, 7MB is ook absoluut niet veel en kleine updates horen gewoon snel te gaan.

Verder zat er idd een foutje in m'n hosts file. Dit heb k nu gefixed.. alleen wordt het er niet sneller

Weet je zeker dat er niet nog iets anders fout zit? Dit klinkt echt als problemen met je host lookup...

Heeft je computer ook nog een echte hostname ipv localhost? Wat als je die gebruikt? Of het IP adres?

[trinite_t]

tomato schreef op woensdag 07 juni 2006 @ 12:39:

Weet je zeker dat er niet nog iets anders fout zit? Dit klinkt echt als problemen met je host lookup...

Heeft je computer ook nog een echte hostname ipv localhost? Wat als je die gebruikt? Of het IP adres?

Als ik een commit oid wil doen en ik heb nog geen opgeslagen wachtwoord wordt er vijwel direct om het wachtwoord gevraagd. Ook bij het intypen van een verkeerd wachtwoord gaat het nog steeds snel.. totdat je een goed wachtwoord intypt... Dan ga je echt zitten wachten.. Dus het lijkt me niet echt in m'n netwerk te zitten... Verder maakt het geen verschil als ik "echte" hostname of ip gebruik ipv localhost... reageert hetzelfde..

[Straphka]

Weet je zeker dat je geen post-commit hooks hebt? Lijkt me wel, maar check ff voor de zekerheid (/path/naar/repo/hooks). De bestanden met tmpl extensie kun je negeren, het gaat om bestanden zonder deze extensie en welke executable zijn.

Ook kun je, als je eenmaal een checkout hebt gedaan, gewoon "svn update" doen, dus zonder de repo erbij te geven. Is het dan ook traag?

Probeer anders een svn+ssh://<REPO>, als dit wel snel gaat, weet je iig dat het geen netwerk probleem is. Als je dit doet, haalt ie je rechten uit je ssh sessie (dus de vraag is of jouw user leesrechten heeft op de repo) en niet uit svn config files.

[ Voor 13% gewijzigd door Straphka op 07-06-2006 16:33 ]

[trinite_t]

dit staat er in de hooks dir van mijn repository:

code:

svn/default/hooks # ls -lah
total 36K
drwxr-xr-x 2 svn svnusers  360 Jun  7 11:09 .
drwxr-xr-x 7 svn svnusers  224 Jun  7 11:09 ..
-rw-r--r-- 1 svn svnusers 2.0K Jun  7 11:09 post-commit.tmpl
-rw-r--r-- 1 svn svnusers 1.6K Jun  7 11:09 post-lock.tmpl
-rw-r--r-- 1 svn svnusers 2.3K Jun  7 11:09 post-revprop-change.tmpl
-rw-r--r-- 1 svn svnusers 1.6K Jun  7 11:09 post-unlock.tmpl
-rw-r--r-- 1 svn svnusers 2.9K Jun  7 11:09 pre-commit.tmpl
-rw-r--r-- 1 svn svnusers 2.0K Jun  7 11:09 pre-lock.tmpl
-rw-r--r-- 1 svn svnusers 2.7K Jun  7 11:09 pre-revprop-change.tmpl
-rw-r--r-- 1 svn svnusers 2.0K Jun  7 11:09 pre-unlock.tmpl
-rw-r--r-- 1 svn svnusers 2.1K Jun  7 11:09 start-commit.tmpl

Zo als het er nu uitziet werkt het wel goed via ssh. Probleem is alleen dat het systeem uiteindelijk alleen svnserve moet ondersteuenen... dit omdat er ook gebruikers mee moeten kunnen werken die geen ssh op hun pc hebben staan (windows clients enzo) Waar zou het aan kunnen liggen dat het via svnserve niet direct werkt, maar wel via ssh

[Straphka]

Humz, dat zou ik zo snel niet weten. Ik weet wel dat je in windows ook gewoon svn over ssh kan gebruiken, iig met tortoisesvn (tortoisesvn.tigris.org). Je geeft dan als repo gewoon svn+ssh://path/nar/repo op en gaan met die banaan (wel ff de ssh pub keys op orde hebben, anders vraagt ie minimaal 2 keer naar je password elke keer dat ie connectie maakt).

Dit is alleen niet echt een oplossing maar een workaround. Je zou kunnen kijken of je de daemon (of de svn client) kan stracen terwijl ie zo lang bezig is, misschien dat je dan ziet dat ie ergen heel lang op wacht.

code:

strace -p <pid van svnserv/svn>

[trinite_t]

Heb strace niet geprobeerd, maar weet nu in ieder geval wel waar het aan ligt:
gevonden op gentoo forum
De meest simpele manier om het te fixen blijkt om in je config

code:

anon-access = read

in te stellen ipv

code:

anon-access = none

Nadeel is dan alleen dat dan iedereen read access op je repository heeft...

Een andere manier schijn (ben het nu aan het uitproberen) is om het apr package te compilen met urandom support. Aangezien /dev/random voor de vertraging zorgt.

Is er misschien iemand die dit een beetje beter kan uitleggen.. zover als ik het nu snap is /dev/urandom een pseudo random generator, en /dev/random een "echte" random generator, omdat hij gebruikt maakt van data die er door je systeem loopt . Ik moet ook zeggen dat deze erg langzaam is bij mij...(te weinig data )

edit:
Het lijkt te werken.. loopt nu iig als een trein

[ Voor 5% gewijzigd door trinite_t op 08-06-2006 16:01 ]

[Straphka]

Zoals ik altijd /dev/random heb begrepen is dit meestal een zg "pseudo device".
Normale i386 compatible pc's hebben geen hardware random number generator, en bieden dus als alternatief /dev/(u)random.

Heb probleem hier is alleen, hoe komt een systeem aan "random" data? Je moet nl wel een uitgangspunt hebben. Dit is opgelost door een systeem continu random data te laten bekijken (mac-adressen, langkomende tcp-paketten, user input zoals muis bewegingen en toetsaanslagen etc). De opgebouwde "randomheid" wordt entropy genoemd.

Als deze entropy "leegraakt", dus als er teveel een beroep word gedaan op /dev/(u)random, duurt het weer even voordat er genoeg is om een nieuw random object uit te spugen. Doe maar eens

code:

 cat /dev/urandom > /tmp/bla

Je zult zien dat het initieel heel snel gaat, maar als je op x aantal mb zit (in mijn geval ~100), gaat het zeer traag.