You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "BRUGGEMAN Jens (JBRG)" <Je...@seco-m.be> on 2005/02/12 10:53:22 UTC
svnserve processes
Hi,
I seem to have an ennoying problem with subversion.
I installed subversion version 1.1.1-r3 on a Linux Gentoo box. I alsoo made
the repositories, configuration went perfect even the usage did.
Quit an amazing system !
On the Gentoo box you have 1 main process being 'svnserve -d -r
/home/repositories'. This runs as deamon as you can see.
When an user wants to performa an update, commit or checkout .. This main
process forks and creates a child process. the child process will do its
thing and close itself and return to the parent (main).
But sometimes, I can't really say when (but often) an update, or commit
takes like for-ever (10-15 minutes) to take place. I already upgrade the
subversion client TortoiseSVN to the latest version to be sure it is not
client-side problem. I alsoo upgraded the svn server to the latest build
being 1.1.3 to be sure this isn't a problem which is already solved.
I have used the command 'strace' on the process so see what is happening
with the child process and why it takes such a long time.
Some users did an update on their working copy and aborted the action
because it took too long. This process is 'idling' now already for about 1
day. Doing nothing. I can kill the process for sure, but isn't there a
time-out on the child processes?
I can paste some logging of a process which has stopped doing anything:
11:21:59 fork(Process 9952 attached
) = 9952
[pid 9952] 11:21:59 getpid() = 9952
[pid 9952] 11:21:59 getrlimit(RLIMIT_STACK, {rlim_cur=RLIM_INFINITY,
rlim_max=RLIM_INFINITY}) = 0
[pid 9952] 11:21:59 close(3) = 0
[pid 9952] 11:21:59 write(4, "( success ( 1 2 ( ANONYMOUS ) ( "..., 52) =
52
[pid 9952] 11:21:59 read(4, "( 2 ( edit-pipeline ) 31:svn://1"..., 4096) =
59
....
[pid 9952] 11:21:59 open("/dev/random", O_RDONLY) = 5
[pid 9952] 11:21:59 read(5, "\25\320XW\362~", 8) = 6
[pid 9952] 11:21:59 read(5, <unfinished ...>
[pid 9952] 11:30:06 <... read resumed> ")}", 2) = 2
Between those 2 actions: 9 minutes before resuming. Why did it even stop? I
got lots of such message, unfinished .. after some time resumed action.
After that line:
[pid 9953] 11:30:06 <... read resumed> "\230\10\226\257t\266U\3", 8) = 8
[pid 9952] 11:30:06 close(5 <unfinished ...>
[pid 9953] 11:30:06 close(5 <unfinished ...>
[pid 9952] 11:30:06 <... close resumed> ) = 0
[pid 9953] 11:30:06 <... close resumed> ) = 0
.... (Lots of actions)
[pid 9952] 11:30:08 unlink("/tmp/report.tmp") = 0
[pid 9952] 11:30:08 write(4, "( success ( ) ) ", 16) = 16
[pid 9952] 11:30:08 read(4, <unfinished ...>
11:30:08 was the latest action the process has done. Doing a read which was
unfinished and never resumed.
I still have the process doing 'ps -ef | grep svn'
root 9952 3630 0 11:21 ? 00:00:00 svnserve -d -r
/home/svnroot/
So the process started at 11:21 .. Took about 9 minutes and did not even
complete.
What could be wrong? Anyone any ideas? I would love to get this problem
solved to get an optimal working situation.
Greetings,
Jens
Re: svnserve processes
Posted by "C. Michael Pilato" <cm...@collab.net>.
Daniel Patterson <da...@danpat.net> writes:
> On some systems, /dev/random is not just a pseudorandom number
> generator. When you read from it, the kernel gathers data from
> various sources (network io, disk io, etc) to generate the random
> data you read.
[...]
> A more detailed explaination is here, along with a perl implementation
> of what I roughly described above.
>
> http://egd.sourceforge.net/
Also note that on systems that have such, you can configure and build
APR with a flag (--with-devrandom[=DEV]) that tells it to use
/dev/urandom (which *is* a pseudorandom number generator) instead of
/dev/random.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svnserve processes
Posted by Daniel Patterson <da...@danpat.net>.
BRUGGEMAN Jens (JBRG) wrote:
> I can paste some logging of a process which has stopped doing anything:
>
> 11:21:59 fork(Process 9952 attached
> ) = 9952
> [pid 9952] 11:21:59 getpid() = 9952
> [pid 9952] 11:21:59 getrlimit(RLIMIT_STACK, {rlim_cur=RLIM_INFINITY,
> rlim_max=RLIM_INFINITY}) = 0
> [pid 9952] 11:21:59 close(3) = 0
> [pid 9952] 11:21:59 write(4, "( success ( 1 2 ( ANONYMOUS ) ( "..., 52) =
> 52
> [pid 9952] 11:21:59 read(4, "( 2 ( edit-pipeline ) 31:svn://1"..., 4096) =
> 59
> ....
> [pid 9952] 11:21:59 open("/dev/random", O_RDONLY) = 5
> [pid 9952] 11:21:59 read(5, "\25\320XW\362~", 8) = 6
> [pid 9952] 11:21:59 read(5, <unfinished ...>
> [pid 9952] 11:30:06 <... read resumed> ")}", 2) = 2
On some systems, /dev/random is not just a pseudorandom number
generator. When you read from it, the kernel gathers data from
various sources (network io, disk io, etc) to generate the random
data you read.
What typically happens is that the kernel gathers "entropy" for
a while, and makes it available to /dev/random. You can usually
read a handful of bytes instantly, but after that, reads often
block until the kernel has decided that it's gathered enough
entropy to feed you more "truely random" data. The faster it
feeds you data on /dev/random, the more information can be deduced
by an attacker who knows how that data is being generated (i.e.
they can send network traffic to your machine to affect the randomness
of the numbers). The delay is an attempt to counter that.
A more detailed explaination is here, along with a perl implementation
of what I roughly described above.
http://egd.sourceforge.net/
That said, 9 minutes is a long time to wait for 2 bytes of new random
data. Perhaps your server is very very idle or has a buggy
/dev/random implementation? I'm not even sure why svnserve needs
random data (authentication?).
You can probably run a bit of a test by hand by simply doing "cat
/dev/random" and seeing how fast you can read from that. You'll
probably find that it's quite slow (when compared to, say, cat
/dev/zero, or /dev/hda).
daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org