You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Stefan Urbat <st...@apastron.lb.shuttle.de> on 2004/07/24 10:15:58 UTC
one performance observation/question and one commit/segfault issue
1. performance: since short I run svnserve 1.0.5 on a PIV 2.8 GHz HT
machine with Debian Sarge, Kernel 2.6.7 and SMT switched on, with a SATA
RAID array (xfs as filesystem) attached, and I think this server performs
great as subversion server.
But when it comes to the clients, there are huge performance differences
among different platforms, I tend to make essentially three performance
classes of them:
a) the fastest are GNU/Linux and Solaris; on the fast machines I can
checkout our huge company library in just one minute, especially our Dual
Opteron (2x1.6 GHz), running SuSE 9.1 x86_64 and ext3 can do so easily,
using both CPUs in parallel results in a little server overload, so the
client performance seems indeed to be best possible. Taking into account
the slower CPUs of our other GNU/Linux and Solaris clients, they seem to
be all on the same level regarding OS and filesystem (also with reiserfs
respective ufs/logging).
b) the medium class are the MS Win clients, approximately requiring three
times of class a) to check out the very same repository, seemingly both
with FAT as with NTFS, same CPU speed compared of course.
c) the worst are the HP-UX and AIX systems, they require up to the 10th
time of class a), for example a POWER 4+ 1.2 GHz AIX 5.2 machine (using
jfs2) is taking about 20 times of the Dual Opteron (using only one cpu
then!), to check this out. Also the older AIX 4.3.3 system performs rather
poor (running jfs) while checking out.
Does anybody know a reason for these striking client performance
differences? It is a switched 100 Mbit/s network, where all these machines
operate without bridges or the like. I have not yet watched the time
behaviour of Mac OS X 10.3 with hfs+, but will do so next week, by the
way, FreeBSD may be tested to in the near future (from the last I would
suppose good client performance, but that's just a guess).
The effect is rather clear client side, because I see virtually no
activity on the server (but then rather slow increasing CPU time of the
svnserve process of course) with c), low activity with class b) and medium
to high (depending on the clients CPU) activity on class a), all requiring
the same total CPU time on the server, as expected.
2. segmentation fault on HP-UX during commit: every time I try to commit a
test file in a test repository or a productive file in the mentioned
library I get a segfault there, since 1.0.5 at least (update to 1.0.6
didn't change behaviour), regardless if I use the default editor vim or the -m
parameter. System is HP-UX 11 on PARISC, 500 MHz.
Here is the final part of the truss output while committing a test file
(that subsequently the directory is locked and needs a cleanup is clear,
no inconsistency is introduced, but I can't check a file in this way of
course), the file is named nochwas, the content in the read statements
contains only the values of the repository version, no changed version
part is seen herein, though sending file is announced:
rename("/home/build/projects/trunk/testCVS/.svn/tmp/text-base/nochwas.svn-base.t
mp", "/home/build/projects/trunk/testCVS/.svn/tmp/text-base/nochwas.svn-base") =
0
open("/home/build/projects/trunk/testCVS/.svn/text-base/nochwas.svn-base", O_RDO
NLY, 0666) = 5
read(5, "u m u c o m m i t t e s t \n", 1024) = 16
read(5, 0x7a000f68, 1024) = 0
close(5) = 0
open("/home/build/projects/trunk/testCVS/.svn/text-base/nochwas.svn-base", O_RDO
NLY, 0666) = 5
poll(0x7a0010a0, 1, 0) = 0
open("/home/build/projects/trunk/testCVS/.svn/tmp/text-base/nochwas.svn-base", O
_RDONLY, 0666) = 6
brk(0x400a0000) = 0
read(5, "u m u c o m m i t t e s t \n", 102400) = 16
read(5, 0x40050260, 102384) = 0
read(6, "u m u c o m m i t t e s t ".., 102400) = 53
read(6, 0x40050295, 102347) = 0
Received signal 11, SIGSEGV, in user mode, [SIG_DFL], partial siginfo
Siginfo: si_code: I_NONEXIST, faulting address: 0x40083390, si_errno: 0
PC: 0xc04fb657, instruction: 0x0cbc0094
exit(11) [implicit] WIFSIGNALED(SIGSEGV)|
WCOREDUMP
Thanks for any advice or comment to those two items in advance...
--
Registered GNU/Linux-User #169380 on http://counter.li.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: one performance observation/question and one commit/segfault
issue
Posted by Branko Čibej <br...@xbc.nu>.
Stefan Urbat wrote:
>On Sat, 24 Jul 2004, [UTF-8] Branko Ä^Libej wrote:
>
>
>
>>My guess is filesystem performance on the client. I've observer myself
>>that Subversion tests take about twice as long to run on a Windows
>>machine than on a (comparable) Linux machine; and since the CPU load is
>>very low, and everything happens localy, filesystem performance is the
>>most probably culprit.
>>
>>
>>
>You are probably right, and I mentioned the kind of filesystems not for
>nothing: when I observed a checkout on that AIX 5.2 running on POWER 4+
>with 1.2 GHz, topas displayed there not notable cpu user or system times,
>but considerable wait times. Due to the fact, that the machine has a very
>fast USCSI subsystem (320 MB/s bus) and disk, jfs(2) seems to be the only
>possible culprit to me. Likely this is similar on other non-Linux/Solaris
>systems more or less too.
>
>
>
>>For example, I've noticed a similar spread of FS performance (Solaris
>>better than Windows better thatn HP-UX) when I was working on another
>>project that has nothing to do with Subversion, but was very I/O bound.
>>
>>
>>
>Considering the hardware data, in comparison AIX/jfs(2) seems to be even
>worse than HP-UX/Vxfs ;-)
>
>
Yes, I noticed the same.
>So there can be done little, eh?
>
Well, optimising (redesigning...) the working copy library could be a
big win... in 2.0.
> But I can recommend my colleagues to
>switch from MS Windows to GNU/Linux at least for one more good reason ;-)
>
>
Oh, yes. :-)
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: one performance observation/question and one commit/segfault
issue
Posted by Stefan Urbat <st...@apastron.lb.shuttle.de>.
On Sat, 24 Jul 2004, [UTF-8] Branko Ä^Libej wrote:
> My guess is filesystem performance on the client. I've observer myself
> that Subversion tests take about twice as long to run on a Windows
> machine than on a (comparable) Linux machine; and since the CPU load is
> very low, and everything happens localy, filesystem performance is the
> most probably culprit.
>
You are probably right, and I mentioned the kind of filesystems not for
nothing: when I observed a checkout on that AIX 5.2 running on POWER 4+
with 1.2 GHz, topas displayed there not notable cpu user or system times,
but considerable wait times. Due to the fact, that the machine has a very
fast USCSI subsystem (320 MB/s bus) and disk, jfs(2) seems to be the only
possible culprit to me. Likely this is similar on other non-Linux/Solaris
systems more or less too.
> For example, I've noticed a similar spread of FS performance (Solaris
> better than Windows better thatn HP-UX) when I was working on another
> project that has nothing to do with Subversion, but was very I/O bound.
>
Considering the hardware data, in comparison AIX/jfs(2) seems to be even
worse than HP-UX/Vxfs ;-)
So there can be done little, eh? But I can recommend my colleagues to
switch from MS Windows to GNU/Linux at least for one more good reason ;-)
--
Registered GNU/Linux-User #169380 on http://counter.li.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: one performance observation/question and one commit/segfault
issue
Posted by Branko Čibej <br...@xbc.nu>.
Stefan Urbat wrote:
>1. performance: since short I run svnserve 1.0.5 on a PIV 2.8 GHz HT
>machine with Debian Sarge, Kernel 2.6.7 and SMT switched on, with a SATA
>RAID array (xfs as filesystem) attached, and I think this server performs
>great as subversion server.
>
>But when it comes to the clients, there are huge performance differences
>among different platforms, I tend to make essentially three performance
>classes of them:
>
>a) the fastest are GNU/Linux and Solaris; on the fast machines I can
>checkout our huge company library in just one minute, especially our Dual
>Opteron (2x1.6 GHz), running SuSE 9.1 x86_64 and ext3 can do so easily,
>using both CPUs in parallel results in a little server overload, so the
>client performance seems indeed to be best possible. Taking into account
>the slower CPUs of our other GNU/Linux and Solaris clients, they seem to
>be all on the same level regarding OS and filesystem (also with reiserfs
>respective ufs/logging).
>
>b) the medium class are the MS Win clients, approximately requiring three
>times of class a) to check out the very same repository, seemingly both
>with FAT as with NTFS, same CPU speed compared of course.
>
>c) the worst are the HP-UX and AIX systems, they require up to the 10th
>time of class a), for example a POWER 4+ 1.2 GHz AIX 5.2 machine (using
>jfs2) is taking about 20 times of the Dual Opteron (using only one cpu
>then!), to check this out. Also the older AIX 4.3.3 system performs rather
>poor (running jfs) while checking out.
>
>Does anybody know a reason for these striking client performance
>differences? It is a switched 100 Mbit/s network, where all these machines
>operate without bridges or the like. I have not yet watched the time
>behaviour of Mac OS X 10.3 with hfs+, but will do so next week, by the
>way, FreeBSD may be tested to in the near future (from the last I would
>suppose good client performance, but that's just a guess).
>
>
My guess is filesystem performance on the client. I've observer myself
that Subversion tests take about twice as long to run on a Windows
machine than on a (comparable) Linux machine; and since the CPU load is
very low, and everything happens localy, filesystem performance is the
most probably culprit.
For example, I've noticed a similar spread of FS performance (Solaris
better than Windows better thatn HP-UX) when I was working on another
project that has nothing to do with Subversion, but was very I/O bound.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org