Hi,
this is the list of open files of my SVN client. What make me wonder is that I
can't see any open file which correlates to a file being checked out. But this
fits the truss output where I only see that the client receives data from the
network and doesn't write any data to files.
Where does Subversion store files temporarily when updating a directory?
Thanks,
- Jan.
clyprae_at_sclybl002 [global]:/opt/calypso/clyprae/dis/app/calypso/jars > pfiles
20821
20821: svn update app/calypso
Current rlimit: 256 file descriptors
0: S_IFSOCK mode:0666 dev:314,0 ino:4772 uid:0 gid:0 size:0
O_RDWR
SOCK_STREAM
SO_DEBUG,SO_REUSEADDR,SO_KEEPALIVE,SO_DONTROUTE,SO_BROADCAST,SO_OOBINLINE,SO_DGRAM_ERRIND,SO_SNDBUF(16384),SO_RCVBUF(5120)
sockname: AF_UNIX
1: S_IFSOCK mode:0666 dev:314,0 ino:4772 uid:0 gid:0 size:0
O_RDWR
SOCK_STREAM
SO_DEBUG,SO_REUSEADDR,SO_KEEPALIVE,SO_DONTROUTE,SO_BROADCAST,SO_OOBINLINE,SO_DGRAM_ERRIND,SO_SNDBUF(16384),SO_RCVBUF(5120)
sockname: AF_UNIX
2: S_IFSOCK mode:0666 dev:314,0 ino:4777 uid:0 gid:0 size:0
O_RDWR
SOCK_STREAM
SO_DEBUG,SO_REUSEADDR,SO_KEEPALIVE,SO_DONTROUTE,SO_BROADCAST,SO_OOBINLINE,SO_DGRAM_ERRIND,SO_SNDBUF(16384),SO_RCVBUF(5120)
sockname: AF_UNIX
3: S_IFDOOR mode:0444 dev:317,0 ino:54 uid:0 gid:0 size:0
O_RDONLY|O_LARGEFILE FD_CLOEXEC door to nscd[198]
/var/run/name_service_door
4: S_IFSOCK mode:0666 dev:314,0 ino:61651 uid:0 gid:0 size:0
O_RDWR
SOCK_STREAM
SO_DEBUG,SO_REUSEADDR,SO_KEEPALIVE,SO_DONTROUTE,SO_BROADCAST,SO_OOBINLINE,SO_DGRAM_ERRIND,SO_SNDBUF(49152),SO_RCVBUF(49640)
sockname: AF_INET 10.168.4.198 port: 44128
peername: AF_INET 10.168.4.253 port: 80
5: S_IFREG mode:0644 dev:92,40001 ino:2671 uid:14301 gid:600 size:181
O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE
kmradke_at_rockwellcollins.com wrote:
> Jan Bernhardt <j.bernhardt_at_gmx.de> wrote on 08/12/2008 11:00:46 AM:
>> hmmm... the checkout contains about 40 files. I suppose that doesn't
> fall in
>> the category "huge amounts of files". But you are right: the load on the
>> client increases, after a short time the client is at 1.
>>
>> This is what the client does all the time:
>>
>> clyprae_at_sclyds002 [global]:/opt/calypso/clyprae/eds > truss -v all -p
> 27523
>> recv(4, " a N j 8 X u r l w j 9 1".., 8192, 0) = 8192
>> pollsys(0xFFBFA7D0, 1, 0xFFBFA758, 0x00000000) = 1
>> fd=4 ev=POLLIN rev=POLLIN
>> timeout: 3600.000000000 sec
>> recv(4, " I 8 V e 1 6 1 x 8 U y 3".., 8192, 0) = 8192
>> pollsys(0xFFBFA7D0, 1, 0xFFBFA758, 0x00000000) = 1
>> fd=4 ev=POLLIN rev=POLLIN
>> timeout: 3600.000000000 sec
>> recv(4, " K e 8 g Y\n I 8 r f D o".., 8192, 0) = 8192
>> pollsys(0xFFBFA7D0, 1, 0xFFBFA758, 0x00000000) = 1
>> fd=4 ev=POLLIN rev=POLLIN
>> timeout: 3600.000000000 sec
>> recv(4, " u T Q n s S S / S C 8 r".., 8192, 0) = 8192
>> pollsys(0xFFBFA7D0, 1, 0xFFBFA758, 0x00000000) = 1
>> fd=4 ev=POLLIN rev=POLLIN
>> timeout: 3600.000000000 sec
>>
>> With a quite low frequency - about 3 receives per second.
>
> Do you see any iostat wait times on the client? I'm guessing
> yes, since you said the load goes to 1...
>
> Kevin R.
>
>
>> kmradke_at_rockwellcollins.com wrote:
>>> Jan Bernhardt <j.bernhardt_at_gmx.de> wrote on 08/12/2008 09:52:05 AM:
>>>> thanks for your comments. Unfortunately the entropy is not the
> culprit.
>>> As for
>>>> the per dir auth I don't think that this is a problem, since the
> server
>>> is not
>>>> loaded and I suppose it would only show when accessing lots of
> possibly
>>> small
>>>> files, which is not the case here.
>>> How loaded is the client machine?
>>>
>>> Particularly, check the disk I/O on the client. The current working
> copy
>>> code will do a
>>> tremendous amount of I/O on the client for large working copies with
> large
>>> numbers of
>>> files. When the client is doing I/O in the working copy, you will see
>
>>> significant pauses
>>> in the data sent between the client and server.
>>> (Or at least this is what I have observed with 20G+ working copies...)
>>>
>>> Kevin R.
>>>
>>>
>>>> Felix Gilcher wrote:
>>>>>> -----Ursprüngliche Nachricht-----
>>>>>> Von: Jan Bernhardt [mailto:j.bernhardt_at_gmx.de]
>>>>>> Gesendet: Dienstag, 12. August 2008 16:22
>>>>>> An: users_at_subversion.tigris.org
>>>>>> Betreff: Checkout via http/webdav hangs
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I'm running SVN 1.4.2 via an Apache HTTPD 2.0.55 over webdav. This
> is
>>> on
>>>>>> Solaris 10 SPARC.
>>>>>>
>>>>>> Some checkouts/updates seem to hang. The request in question
> involve
>>>>>> checking out a directory worth 350 MB. When I look at the Apache
>>> worker
>>>>>> handling my request I see that it accesses the revision in which
> this
>>>>>> directory was created:
>>>>>>
>>>>> [snipped out traces]
>>>>>
>>>>>> My interpretation is that the process does read the revision
>>> continuesly
>>>>>> and answers back to the client, but very slowly. Checking out via
>>>>>> file:/// access does work.
>>>>>>
>>>>>> Any idea, what's going on here?
>>>>>>
>>>>> Wild guess, as you didn't mention it: Are you checking out via
> https?
>>> You
>>>> might be running out of entropy. There have been reports of that
> which
>>> fit
>>>> your description. If yes, you could check whether http does work
> faster
>>> for you.
>>>>> Another option would be that you're using per-directory access
> control
>>> [1]
>>>> which can create a big load on the server. You might want to disable
>>> that at
>>>> least for testing purposes [2].
>>>>>> Thanks,
>>>>>>
>>>>>> - Jan.
>>>>>>
>>>>>>
>>>>> Good luck
>>>>>
>>>>> felix
>>>>>
>>>>>
>>>>> [1]
> http://svnbook.red-bean.com/nightly/de/svn.serverconfig.httpd.html#svn.
>>>> serverconfig.httpd.authz.perdir
>>>>> [2]
> http://svnbook.red-bean.com/nightly/de/svn.serverconfig.httpd.html#svn.
>>>> serverconfig.httpd.authz.pathauthzoff
>>>>> --
>>>>> Felix Gilcher
>>>>>
>>>>> E-Mail: mailto:felix.gilcher_at_exozet.com
>>>>> URL: http://www.exozet.com/
>>>>>
>>>>> Geschäftsführer: Frank Alexander Zahn
>>>>> Handelsregisternummer: HRB 58797 Amtsgericht Charlottenburg
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
>>>> For additional commands, e-mail: users-help_at_subversion.tigris.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
>>> For additional commands, e-mail: users-help_at_subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-08-13 10:44:20 CEST