Samba share 'hangt' regelmatig sinds TortoiseSVN install.

[Yggdrasil]

Beste tweakers,

Op mijn werk doen een vijftal web developers hun ontwikkelwerk in een eigen subversion working-copy, die zich bevindt op een Samba share op een debian linux server. Deze server bevindt zich op het LAN via een 100 Mbit switched ethernet. Iedereen heeft zijn eigen working-copy natuurlijk maar die staat dus wel 'remote'.

We doen dit pas sinds enkele weken, en gebruiken TortoiseSVN op onze Windows XP pc's om deze 'remote' working-copies te beheren. Op zich werkt dat goed. De working copies worden via Apache mass-virtual-hosting 'geëxporteerd' als virtual domains, zodat elke ontwikkelaar zijn eigen working-copy kan benaderen als website via de webserver. Deze apache host draait op dezelfde server als Samba.

Wanneer we echter met meerdere mensen op die shares werken 'hangt' de verbinding met de share periodiek. Dat wil zeggen, zowel Zend Studio als explorer geven een zandloper, die pas na een minuut of twee weer verdwijnt. Save of load bewerkingen die in die periode plaatsvinden worden daarna gewoon voltooid. Overige netwerkactiviteiten, zoals IM en webbrowsen werken in die tijd gewoon door.

Hoe meer mensen er op werken, hoe vaker de vastlopers. In het begin, met 2 of 3 actieve gebruikers, was het eens in het half uur of uur. Vandaag werkten we met een stuk of 5 ontwikkelaars en 4 testers aan een site en lag de verbinding elke paar minuten plat. Compleet onwerkbaar natuurlijk.

De load op de server is op dat moment slechts 0.30. De netwerkverbindingen zijn allemaal switched en 100Mbit, wat toch voldoende zou moeten zijn voor nog geen 10 simultane gebruikers. Vroeger vond de ontwikkeling plaats op dezelfde netwerkdrive, maar zonder TortoiseSVN te gebruiken. Iedereen heeft zijn virusscanners ingesteld om niet op netwerkdrives te scannen. TortoiseSVN is ingesteld om wel Icon Overlays te tonen op netwerkdrives.

We hebben nog geen duidelijke oorzaak kunnen vinden, en ik hoop dat de verzamelde kennis van de Tweakers hier hulp kan bieden. Wat voor analyse kunnen we toepassen om de oorzaak te pinpointen?

Bij voorbaat dank!

Onze smb.conf:

# Global parameters
[global]
        security = SHARE
        obey pam restrictions = Yes
        passdb backend = tdbsam
        passwd program = /usr/bin/passwd %u
        passwd chat = *Enter\snew\sUNIX\spassword:* %n\n *Retype\snew\sUNIX\spassword:* %n\n .
        syslog = 0
        log file = /var/log/samba/log.%m
        max log size = 1000
        dns proxy = No
        panic action = /usr/share/samba/panic-action %d
        invalid users = root
        socket options = IPTOS_LOWDELAY TCP_NODELAY
        domain master = yes
        use sendfile = yes
        local master = yes
        preferred master = yes
        os level = 65
        name resolve order = lmhosts hosts bcast
        level2 oplocks = yes
        read raw = yes
        debug level = 1
        guest ok = yes
        browseable = yes
        public = yes
        netbios name = batman
        interfaces = 10.0.0.0/24 127.0.0.1
        wins support = yes
        hosts deny = 0.0.0.0/0
        hosts allow = 127.0.0.1 10.0.0.0/24
        bind interfaces only = yes
[Websites]
        comment = Websites
        path = /var/www
        read only = no
        create mask = 0775
        directory mask = 0775
        force user = www-data
        force create mode = 0664
        force directory mode = 0775
        delete readonly = yes
        dos filemode = yes

[Herko_ter_Horst]

Sorry, maar deze opzet snap ik niet.

Waarom staan de working copies remote en niet alleen de SVN repository? En wat is het nut van working copies via Apache ontsluiten? Het idee achter SVN is dat je elk op een lokale kopie van (een deel van) de repository werkt (checkout) en eens in de zoveel tijd synchroniseert (update/commit).

De repository kun je op verschillende manier remote benaderen. Dat kan inderdaad via een netwerk share, maar via een server (meestal Apache httpd met mod_dav_svn) is waarschijnlijk handiger.

Door de vele kleine losse bestandjes die een SVN working copy gebruikt, is het zeer inefficient om een working copy op een netwerk share te hebben staan. TortoiseSVN 'verergert' dit door voor de icon overlays de "deep state" te gaan bepalen.

[ Voor 6% gewijzigd door Herko_ter_Horst op 24-11-2008 15:50 ]

[remmelt]

Dit kan wel werken maar is nooit heel snel. Wij hebben het zo werkend gehad in een klein kantoor met 5 of 6 ontwikkelaars en dan is het te doen.

Wat de boel traag kan maken is dat TortoiseSVN voortdurend aan het checken is of alle bestanden nog up to date zijn of niet, zodat het de icoontjes kan aanpassen. Dit kan je uitzetten en zal de snelheid ontzettend verhogen. Netwerkverkeer wordt dan weer een beetje normaal. Rechtsklik op een SVN-map, Tortoise, Settings, Icon Overlays, Network Drives uitvinken. Dat zou moeten helpen.

Misschien is het hoe dan ook beter om de boel via Apache te laten lopen? Kan je er van buiten ook op.

Herko: een working copy op de server kan wel handig zijn, je hoeft dan niet op elk workstation apache te installeren, een apache die niet hetzelfde is als de ontwikkelserver/produktieserver (windows, andere configs, etc). Zeker als je je working copy dan met de command line tools bewerkt, kan het supersnel werken. Als je echter TortoiseSVN via Samba gaat gebruiken, loopt de boel in de soep, voornamelijk wegens de overlays. Zonder de overlays is het tot een man of 6 (misschien meer?) best te doen.

Yggdrasil: misschien zou je eens kunnen proberen of de command line tools op de server zelf nog wel snel werken tijdens een network outage?

[ Voor 33% gewijzigd door remmelt op 24-11-2008 15:53 ]

[Herko_ter_Horst]

remmelt schreef op maandag 24 november 2008 @ 15:49:
Herko: een working copy op de server kan wel handig zijn, je hoeft dan niet op elk workstation apache te installeren, een apache die niet hetzelfde is als de ontwikkelserver/produktieserver (windows, andere configs, etc). Zeker als je je working copy dan met de command line tools bewerkt, kan het supersnel werken.

Ik zou dan liever een test-server (of meerdere in verschillende virtual machines) maken die (al dan niet automatisch) een update doet uit de repository.

[Yggdrasil]

@ Herko_ter_Horst: Ja, ik weet dat dit niet de aanbevolen werkwijze is, maar we hebben bewust gekozen voor deze methode. In plaats van op iedere pc full-time een WAMP stack te moeten draaien en synchroon te moeten houden, kunnen we zo op onze ontwikkelserver werken. Dat scheelt vooral resources op onze pc's (die niet al te snel zijn, en ook het zware Zend Studio for Eclipse moeten draaien), en het voorkomt het moeten installeren van diverse obscure apache en php modules op elke pc. De working copies worden via Apache ontsloten omdat Web Development nu eenmaal meer iteratief is dan traditionele software ontwikkeling: edit, save editor, reload browser, repeat, etc. Mensen wijzen graag naar best-practices maar die zijn niet voor iedereen het best.

De repo is overigens via mod_dav_svn beschikbaar, dus hij is al van binnen en buiten te bereiken.

@remmelt: Die overlay icons zouden inderdaad wel eens voor problemen kunnen zorgen. Dat is zeker een goed idee. Ik zou ze wel missen overigens

[Yggdrasil]

Herko_ter_Horst schreef op maandag 24 november 2008 @ 15:58:
[...]

Ik zou dan liever een test-server (of meerdere in verschillende virtual machines) maken die (al dan niet automatisch) een update doet uit de repository.

Dat hebben we overwogen, maar dan moet je voor elke iteratie een commit doen. Als je snel iteratief ontwikkeld is dat echt een hindernis. Nu commit elk van ons al meerdere keren per uur, maar dat wordt dan echt elke 5 minuten. Het commit log wordt dan iets van: "aap", "sterf", "aaargh" vermoed ik.

Anyway, dit hebben we heel bewust gekozen. Het pas goed bij onze ontwikkelwerkwijze. Op ons huidige probleem na zijn we heel tevreden, dus zullen we weer on-topic gaan?

[leuk_he]

remmelt schreef op maandag 24 november 2008 @ 15:49:

Wat de boel traag kan maken is dat TortoiseSVN voortdurend aan het checken is of alle bestanden nog up to date zijn of niet, zodat het de icoontjes kan aanpassen. Dit kan je uitzetten en zal de snelheid ontzettend verhogen. Netwerkverkeer wordt dan weer een beetje normaal. Rechtsklik op een SVN-map, Tortoise, Settings, Icon Overlays, Network Drives uitvinken. Dat zou moeten helpen.

Op op een locale file systeem op XP , zeker met de de optie om ook de subdirecoties te chekcen kost dat de nodige performance..

[remmelt]

Naast het uitzetten van de overlays kun je proberen niet via smb maar via mod_dav_svn lokaal te werken. Scheelt dat? Kan je waarschijnlijk je overlays aan laten. Of zoals gezegd op de command line, werkt snel maar ook minder handig voor sommige dingen (diffs, bv)

Ik snap jullie werkwijze erg goed, zo heb ik ook jaren gewerkt. Pas sinds kort overgestapt op een lokale LAMP in een VM omdat ik dan met m'n laptop ook thuis kan zitten.

[Herko_ter_Horst]

Hoe wil je via mod_dav_svn lokaal werken, gezien de eis om de working copy op de server te houden? De wijze van benadering van de repository heeft toch niets te maken met dit probleem?

[ Voor 30% gewijzigd door Herko_ter_Horst op 24-11-2008 16:39 ]

[remmelt]

Kan toch makkelijk?
svn co http://server/svn/project/trunk map
Maar dan in TortoiseSVN natuurlijk en met de map op de smb share.

Het verschil is dat TortoiseSVN de svn server niet meer via smb maar via apache benadert. Dat zou de snelheid kunnen verhogen, maar ik verwacht er niet heel veel van. We hebben dit probleem zelf ook eens onderzocht en zijn toen tot de conclusie gekomen dat de overlays uit moesten. In de oude situatie werd de "lokale" kopie EN svn via smb benaderd (toch?)

Hoe dan ook, je hebt gelijk, het zal weinig uitmaken.

[ Voor 22% gewijzigd door remmelt op 24-11-2008 16:49 ]

[Herko_ter_Horst]

remmelt schreef op maandag 24 november 2008 @ 16:45:
Kan toch makkelijk?
svn co http://server/svn/project/trunk map
Maar dan in TortoiseSVN natuurlijk en met de map op de smb share.

Ah ok, ik dacht even dat je een advanced remote filesystem via dav_svn in gedachten had

Hoe dan ook, je hebt gelijk, het zal weinig uitmaken.

Ok.

@TS: heb je TortoiseSVN eigenlijk wel nodig als je Eclipse gebruikt? Met de Subclipse plugin kun je e.e.a. ook vanuit Eclipse regelen (probleem met overlays hou je waarschijnlijk, maar ook in Subclipse kun je die uitzetten). Ik heb met TortoiseSVN vaak het probleem dat het tortoisesvncache.exe process op een gegeven moment veel geheugen in gaat nemen en erg traag wordt, ook lokaal (wel op een paar behoorlijk grote working copies). Ik heb het idee dat Subclipse hier iets handiger mee omgaat.

[ Voor 39% gewijzigd door Herko_ter_Horst op 24-11-2008 17:14 ]

[Yggdrasil]

remmelt schreef op maandag 24 november 2008 @ 16:45:
In de oude situatie werd de "lokale" kopie EN svn via smb benaderd (toch?)

Nee, de repo is altijd al benaderd via mod_dav_svn. Alleen de working copies zijn via SMB benaderd.

[Yggdrasil]

Herko_ter_Horst schreef op maandag 24 november 2008 @ 16:54:
@TS: heb je TortoiseSVN eigenlijk wel nodig als je Eclipse gebruikt? Met de Subclipse plugin kun je e.e.a. ook vanuit Eclipse regelen (probleem met overlays hou je waarschijnlijk, maar ook in Subclipse kun je die uitzetten). Ik heb met TortoiseSVN vaak het probleem dat het tortoisesvncache.exe process op een gegeven moment veel geheugen in gaat nemen en erg traag wordt, ook lokaal (wel op een paar behoorlijk grote working copies).

Dat is nog wel een goede optie ja. Eclipse vereist een expliciete refresh om het project en de overlays in sync te brengen met het filesystem. Zal waarschijnlijk minder zwaar zijn dan tsvncache.exe.

[remmelt]

Terechte opmerking, maar ik vind Tortoise makkelijker werken dan Subclipse. Bij mij hebben de overlays in Eclipse nooit echt goed gewerkt, vooral niet als je en Subclipse en Tortoise en cmdline gaat mengen. Die expliciete refreshes duren bij een flink project met bijvoorbeeld Drupal als framework vrij lang. Leer te leven zonder de overlays, dat is op dit moment het enige wat ik je kan aanraden. Te doen hoor!

[Herko_ter_Horst]

vooral niet als je en Subclipse en Tortoise en cmdline gaat mengen

Ah!
Als je alles via Eclipse/Subclipse doet, hoef je niet (of nauwelijks) te refreshen.

[ Voor 6% gewijzigd door Herko_ter_Horst op 24-11-2008 17:23 ]

[Barracuda_82]

Eclipse draait bijna niet op mijn computer, dus dat zal niet echt een optie zijn denk ik. Of ik moet een nieuwe high-end computer krijgen van de baas...

Edit: ik ben trouwens een collega van Ygdrasil

[ Voor 15% gewijzigd door Barracuda_82 op 25-11-2008 08:35 ]

[remmelt]

Beetje extra geheugen moet toch te regelen zijn?

[Barracuda_82]

remmelt schreef op dinsdag 25 november 2008 @ 13:49:
Beetje extra geheugen moet toch te regelen zijn?

Ja... maar dat is ook niet zo'n succes gebleken... Maar goed, da's weer een ander verhaal. Back on topic graag!

Vandaag overigens geen een keer last gehad van "het probleem"...

[remmelt]

Ja, vertel eens, heeft dit het opgelost?

[Yggdrasil]

Nog niet iedereen heet de overlay icons uitgeschakeld, maar ik bijv. wel. Het lijkt wel effect te hebben. We zaten dus waarschijnlijk nèt over de kritische grens heen.

We moeten nog een stresstest doen om te kijken of het ook onder grote drukte goed gaat.

Overigens ben ik nu volledig in Zend Studio for Eclipse aan het werken en de Subversive plugin doet het ook best goed. De subversion functies en icoontjes zijn goed bruikbaar en zolang je niet te veel buiten Eclipse om doet hoef je weinig te 'refreshen' en blijft het dus fijn werken. Ik merk wel dat TortoiseSVN vaak net wat handiger in elkaar zit, dus sommige handelingen, zoals mergen van branches doe ik nog liever via Tortoise. Ook is de log viewer van Tortoise handiger vind ik.

Al met al is het even wennen, maar denk ik dat mijn collega's er ook best me zouden kunnen werken. Toch de baas maar eens gaan lastig vallen over hardware upgrades.