You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Martin MAURER <ma...@email.de> on 2003/08/03 14:32:23 UTC
subversion 0.26 performance problem
Please CC me in replies - i am not subscribed to this list.
Hi everybody,
I got quite a strange subversion performance problem:
i have a repository consisting of the web tree of my company.
(the data is not important, it has been created using the backups - just
evaluating svn at the moment)
the repo consists of about 30.000 files in 55 revisions.
The SVN dir has 388 MB
When i start "svnlook tree" on that repo, then it starts quite ok.
But as soon as it reaches a directory where i have about 4.000 images
(jpg,gif) it is getting very slow (a few seconds per file).
CPU is idle and Filesystem is not under heavy load too.
Similar problem when using "svnadmin dump". getting slow when the images
dir is reached. I even had a freeze after trying this one (only tried
once so far). I did a "svnadmin recover" before doing the "svnadmin
dump".
I realized this problem, when i tried to access the repository using
viewcvs (from cvs). I can browse most parts of the repository, but when
i reach the images directory i get a timeout and when i let viewcvs run
for a _long_ time (hours), then it gets killed (i guess because of
memory).
I did one test which did NOT reproduce that problem: i copied all the
4000 images to another direcoty and created a new repository just
importing them. importing is quite slow, but i guess thats ok. svnlook
then works perfectly. (don't know if that information helps, but better
telling too much than too little :)
I use svn 0.26 on debian sid.
(as you see below: db-4.1)
greetings
Martin Maurer
some additional data:
(509)(0)/scratch/lonestar> ldd /usr/bin/svnlook
libsvn_repos-1.so.0 => /usr/lib/libsvn_repos-1.so.0 (0x40027000)
libsvn_fs-1.so.0 => /usr/lib/libsvn_fs-1.so.0 (0x4003b000)
libsvn_delta-1.so.0 => /usr/lib/libsvn_delta-1.so.0 (0x4005c000)
libsvn_diff-1.so.0 => /usr/lib/libsvn_diff-1.so.0 (0x40064000)
libsvn_subr-1.so.0 => /usr/lib/libsvn_subr-1.so.0 (0x4006a000)
libaprutil-0.so.0 => /usr/lib/libaprutil-0.so.0 (0x4008c000)
libldap.so.2 => /usr/lib/libldap.so.2 (0x4009f000)
liblber.so.2 => /usr/lib/liblber.so.2 (0x400d8000)
libdb-4.1.so => /usr/lib/libdb-4.1.so (0x400e5000)
libexpat.so.1 => /usr/lib/libexpat.so.1 (0x40192000)
libapr-0.so.0 => /usr/lib/libapr-0.so.0 (0x401af000)
librt.so.1 => /lib/librt.so.1 (0x401cb000)
libm.so.6 => /lib/libm.so.6 (0x401dc000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x401fe000)
libnsl.so.1 => /lib/libnsl.so.1 (0x4022b000)
libdl.so.2 => /lib/libdl.so.2 (0x4023e000)
libc.so.6 => /lib/libc.so.6 (0x40241000)
libpthread.so.0 => /lib/libpthread.so.0 (0x40351000)
libresolv.so.2 => /lib/libresolv.so.2 (0x403a0000)
libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0x403b1000)
libgnutls.so.7 => /usr/lib/libgnutls.so.7 (0x403c3000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
libtasn1.so.0 => /usr/lib/libtasn1.so.0 (0x403f5000)
libgcrypt.so.1 => /usr/lib/libgcrypt.so.1 (0x40403000)
libz.so.1 => /usr/lib/libz.so.1 (0x4043b000)
(510)(0)/scratch/lonestar> ldd /usr/bin/svn
libsvn_client-1.so.0 => /usr/lib/libsvn_client-1.so.0
(0x40027000)
libsvn_wc-1.so.0 => /usr/lib/libsvn_wc-1.so.0 (0x40044000)
libsvn_ra-1.so.0 => /usr/lib/libsvn_ra-1.so.0 (0x40066000)
libsvn_diff-1.so.0 => /usr/lib/libsvn_diff-1.so.0 (0x40069000)
libsvn_ra_local-1.so.0 => /usr/lib/libsvn_ra_local-1.so.0
(0x4006f000)
libsvn_repos-1.so.0 => /usr/lib/libsvn_repos-1.so.0 (0x40074000)
libsvn_fs-1.so.0 => /usr/lib/libsvn_fs-1.so.0 (0x40087000)
libsvn_ra_dav-1.so.0 => /usr/lib/libsvn_ra_dav-1.so.0
(0x400a9000)
libsvn_ra_svn-1.so.0 => /usr/lib/libsvn_ra_svn-1.so.0
(0x400ba000)
libsvn_delta-1.so.0 => /usr/lib/libsvn_delta-1.so.0 (0x400c4000)
libsvn_subr-1.so.0 => /usr/lib/libsvn_subr-1.so.0 (0x400cc000)
libaprutil-0.so.0 => /usr/lib/libaprutil-0.so.0 (0x400ee000)
libldap.so.2 => /usr/lib/libldap.so.2 (0x40101000)
liblber.so.2 => /usr/lib/liblber.so.2 (0x4013a000)
libdb-4.1.so => /usr/lib/libdb-4.1.so (0x40147000)
libexpat.so.1 => /usr/lib/libexpat.so.1 (0x401f4000)
libapr-0.so.0 => /usr/lib/libapr-0.so.0 (0x40211000)
librt.so.1 => /lib/librt.so.1 (0x4022d000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x4023e000)
libnsl.so.1 => /lib/libnsl.so.1 (0x4026c000)
libdl.so.2 => /lib/libdl.so.2 (0x4027f000)
libneon.so.23 => /usr/lib/libneon.so.23 (0x40282000)
libssl.so.0.9.7 => /usr/lib/i686/cmov/libssl.so.0.9.7
(0x40297000)
libcrypto.so.0.9.7 => /usr/lib/i686/cmov/libcrypto.so.0.9.7
(0x402c6000)
libxml2.so.2 => /usr/lib/libxml2.so.2 (0x403b7000)
libpthread.so.0 => /lib/libpthread.so.0 (0x4049d000)
libz.so.1 => /usr/lib/libz.so.1 (0x404ec000)
libm.so.6 => /lib/libm.so.6 (0x404f9000)
libc.so.6 => /lib/libc.so.6 (0x4051a000)
libresolv.so.2 => /lib/libresolv.so.2 (0x4062a000)
libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0x4063b000)
libgnutls.so.7 => /usr/lib/libgnutls.so.7 (0x4064d000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
libtasn1.so.0 => /usr/lib/libtasn1.so.0 (0x4067f000)
libgcrypt.so.1 => /usr/lib/libgcrypt.so.1 (0x4068d000)
Re: subversion 0.26 performance problem
Posted by cm...@collab.net.
Martin MAURER <ma...@email.de> writes:
> Hi I did something which might help debugging:
> I ran svnlook in gdb and hit Ctrl-C when the timeouts occurred.
> I hope i hit the correct time, but as the problems seem to correspond
> to the select call and this is where i got this result, it looks ok.
> Don't know if this helps - anyways here is the backtrace:
Excellent debugging info, Martin! I'll try to check this out when I
get back from Morning Appointment/Errand #1. :-) Of course, others on
the list are encouraged to dive on in, too.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: subversion 0.26 performance problem
Posted by Martin MAURER <ma...@email.de>.
Hi I did something which might help debugging:
I ran svnlook in gdb and hit Ctrl-C when the timeouts occurred.
I hope i hit the correct time, but as the problems seem to correspond
to the select call and this is where i got this result, it looks ok.
Don't know if this helps - anyways here is the backtrace:
#0 0x4034da9e in select () from /lib/libc.so.6
#1 0x401905e8 in db_xa_switch_4001 () from /usr/lib/libdb-4.1.so
#2 0x40662a38 in ?? ()
#3 0xbffff0e0 in ?? ()
#4 0x40169635 in __os_sleep_4001 () from /usr/lib/libdb-4.1.so
#5 0x40161ed0 in __memp_alloc_4001 () from /usr/lib/libdb-4.1.so
#6 0x40163117 in __memp_fget_4001 () from /usr/lib/libdb-4.1.so
#7 0x40111ed3 in __bam_search_4001 () from /usr/lib/libdb-4.1.so
#8 0x40109607 in __bam_c_rget_4001 () from /usr/lib/libdb-4.1.so
#9 0x40106fab in __bam_c_dup_4001 () from /usr/lib/libdb-4.1.so
#10 0x40124098 in __db_c_get_4001 () from /usr/lib/libdb-4.1.so
#11 0x4011ec7a in __db_get_4001 () from /usr/lib/libdb-4.1.so
#12 0x400427e0 in svn_fs__bdb_get_node_revision (noderev_p=0xbffff4c0, fs=0x8066c08, id=0x81a9948, trail=0x80b7050) at ../subversion/libsvn_fs/bdb/nodes-table.c:197
#13 0x4004509b in get_node_revision (noderev_p=0xbffff4e8, node=0x81a9930, trail=0x80b7050) at ../subversion/libsvn_fs/dag.c:208
#14 0x40045208 in svn_fs__dag_get_node (node=0xbffff54c, fs=0x8066c08, id=0x825bf00, trail=0x80b7050) at ../subversion/libsvn_fs/dag.c:258
#15 0x400476fa in svn_fs__dag_open (child_p=0xbffff54c, parent=0x81b4af8, name=0x81b4c70 "1222_logo_gross.gif", trail=0x80b7050) at ../subversion/libsvn_fs/dag.c:1460
#16 0x4004e532 in open_path (parent_path_p=0xbffff5b4, root=0x807a390, path=0x809cd18 "www/devel/pictures/1222_logo_gross.gif", flags=0, trail=0x80b7050) at ../subversion/libsvn_fs/tree.c:495
#17 0x4004ec03 in get_dag (dag_node_p=0xbffff5d8, root=0x807a390, path=0x809cd18 "www/devel/pictures/1222_logo_gross.gif", trail=0x80b7050) at ../subversion/libsvn_fs/tree.c:773
#18 0x4004ee7f in txn_body_node_kind (baton=0xbffff650, trail=0x80b7050) at ../subversion/libsvn_fs/tree.c:902
#19 0x4004ddc5 in svn_fs__retry_txn (fs=0x8066c08, txn_body=0x4004ee4e <txn_body_node_kind>, baton=0xbffff650, pool=0x80b7018) at ../subversion/libsvn_fs/trail.c:132
#20 0x4004ef7b in svn_fs_is_dir (is_dir=0xbffff6a8, root=0x807a390, path=0x809cd18 "www/devel/pictures/1222_logo_gross.gif", pool=0x80b7018) at ../subversion/libsvn_fs/tree.c:946
#21 0x0804b113 in print_tree (root=0x807a390, path=0x809cd18 "www/devel/pictures/1222_logo_gross.gif", id=0x816aa90, indentation=4, show_ids=0, pool=0x80b7018) at ../subversion/svnlook/main.c:993
#22 0x0804b2a7 in print_tree (root=0x807a390, path=0x808e988 "www/devel/pictures", id=0x80a2a08, indentation=3, show_ids=0, pool=0x809ca88) at ../subversion/svnlook/main.c:1025
#23 0x0804b2a7 in print_tree (root=0x807a390, path=0x80804e8 "www/devel", id=0x80852c8, indentation=2, show_ids=0, pool=0x808e6b8) at ../subversion/svnlook/main.c:1025
#24 0x0804b2a7 in print_tree (root=0x807a390, path=0x8054ca8 "www", id=0x807e930, indentation=1, show_ids=0, pool=0x8080370) at ../subversion/svnlook/main.c:1025
#25 0x0804b2a7 in print_tree (root=0x807a390, path=0x804e40a "", id=0x8078340, indentation=0, show_ids=0, pool=0x8054788) at ../subversion/svnlook/main.c:1025
#26 0x0804bdd8 in do_tree (c=0x8054990, show_ids=0, pool=0x8054788) at ../subversion/svnlook/main.c:1351
#27 0x0804c4fc in subcommand_tree (os=0x80548a8, baton=0xbffff9d0, pool=0x8054788) at ../subversion/svnlook/main.c:1557
#28 0x0804cddc in main (argc=3, argv=0xbffffa74) at ../subversion/svnlook/main.c:1816
Re: subversion 0.26 performance problem
Posted by Martin MAURER <ma...@email.de>.
On Mon, 2003-08-04 at 07:06, cmpilato@collab.net wrote:
> Martin MAURER <ma...@email.de> writes:
>
> > I got quite a strange subversion performance problem:
> > i have a repository consisting of the web tree of my company.
> > (the data is not important, it has been created using the backups - just
> > evaluating svn at the moment)
> > the repo consists of about 30.000 files in 55 revisions.
> > The SVN dir has 388 MB
> >
> > When i start "svnlook tree" on that repo, then it starts quite ok.
> > But as soon as it reaches a directory where i have about 4.000 images
> > (jpg,gif) it is getting very slow (a few seconds per file).
> > CPU is idle and Filesystem is not under heavy load too.
>
> Martin, I'm sure there are several developers who would be interested
> in seeing this behavior first-hand. Is your repository private? That
> is, could you make a tarball of it and provide a URL? (If the
> contents are private, and you trust me not to disseminate them, you
> could send me the URL privately).
well the problem is, that this data is the web-tree of the company I am
working at. So I dont want to hand that out unless _absolutely_
necessary.
I suggest the following: We first try to debug this with you just
telling me what to do. If we come to the conclusion that this won't help
i could give you shell access to my machine - would that be an
acceptable solution ? (still feels better having the data on my machine
than passing it on)
If that is not doable, then i will give you (privately) access to the
tarball. But I get a headache when thinking of the last solution.
>
> Secondly (which should perhaps be "firstly") -- are you able to debug
> this at all? I'm not sure where to start -- maybe running svnlook
> under strace or something. Or, can you play with the number of files
> in that directory and see how the behavior is affected? If you cut
> the number from 4000 to 2000, is the time between each file is handled
> also cut roughly in half?
well I did a strace run on svnlook (see below). Looks interesting, as I
get all those select timeouts. I _dont_ get those when doing svnlook on
a repo, where i only added the 4000 images which make the problem in the
big repo.
If you want me to run any further tests, just tell me.
BTW: on irc i am "lonestar". I try to be online in svn as much as
possible.
Another thing: yesterday I restarted the svndump, and it didn't freeze
that time. I had to interrupt it after about 6 hours as I went to sleep.
I did some statistics: in 15 minutes i got 51 files dumped. (=3.4 files
per minute).
The biggest image is 370.000 bytes - though only 6 are above 100.000
bytes. The average size is 10.500 bytes.
My machine is an Athlon 1700 XP with 512 Mb Ram and an average IBM 40 GB
IDE HD.
I just added a svnadmin dump trace too:
This one is funny: When i start svndump it work sperfectly for some
time. No timeouts, reasonably fast. But then at some time the select
timeouts occur. And from there on everything is slow.
greetings
Martin
strace -T -tt svnlook tree SVN > out
Output
...
13:35:26.729220 pread(3,
"\253\10\0\0C\312\16\0\335\0\0\0\0\0\0\0\0\0\0\0\225\0\314"..., 4096,
905216) = 4096 <0.000058>
13:35:26.730104 select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
<0.998978>
13:35:27.729282 pread(9,
"=\10\0\0\\\202\10\0\205\4\0\0\0\0\0\0\367\4\0\0t\0\300"..., 4096,
4739072) = 4096 <0.000053>
13:35:27.730119 pread(10,
"\265\7\0\0\261~\v\0\246u\0\0\256u\0\0\0\0\0\0\1\0\231\f"..., 4096,
123363328) = 4096 <0.000109>
13:35:27.742957 select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
<0.996017>
13:35:28.739221 pread(3,
"\21\2\0\0\201\245\5\0\31\1\0\0\200\0\0\0\201\0\0\0\232"..., 4096,
1150976) = 4096 <0.000058>
13:35:28.740260 pread(10,
"\261\10\0\0M\337\2\0\344t\0\0\0\0\0\0P\271\0\0Y\0p\n\2"..., 4096,
122568704) = 4096 <0.000063>
13:35:28.753468 pread(3,
"@\10\0\0\356\30\v\0\0\1\0\0g\0\0\0h\0\0\0\232\0\374\1\1"..., 4096,
1048576) = 4096 <0.000077>
13:35:28.767650 select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
<0.991321>
13:35:29.759222 pread(3,
"\250\10\0\0C\257\17\0\335\1\0\0\0\0\0\0U\2\0\0l\0\354\10"..., 4096,
1953792) = 4096 <0.000052>
13:35:29.759468 select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
<0.999563>
13:35:30.759251 pread(3,
"\r\6\0\0\262V\5\0\266\1\0\0\7\0\0\0u\1\0\0Z\0\350\7\1\5"..., 4096,
1794048) = 4096 <0.000059>
13:35:30.760572 select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
<0.998465>
13:35:31.759273 pread(10,
"\265\7\0\0\1\364\t\0\16u\0\0\17u\0\0\ru\0\0\1\0\346\17"..., 4096,
122740736) = 4096 <0.000057>
13:35:31.759747 select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
<0.999268>
13:35:32.759222 pread(10,
"\265\7\0\0[M\v\0\361t\0\0\362t\0\0\251t\0\0\1\0\346\17"..., 4096,
122621952) = 4096 <0.000058>
13:35:32.771856 select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
<0.997150>
13:35:33.769245 pread(3,
"\251\10\0\0\342\276\0\0e\1\0\0\0\0\0\0\335\1\0\0t\0T\10"..., 4096,
1462272) = 4096 <0.000054>
13:35:33.769464 pread(3,
"4\10\0\0\7\347\0\0\227\1\0\0V\1\0\0W\1\0\0d\0\370\6\1\5"..., 4096,
1667072) = 4096 <0.000028>
13:35:33.770102 pread(10,
"?\10\0\0007\373\r\0\310\235\0\0\0\0\0\0\206&\0\0p\0\0\t"..., 4096,
165445632) = 4096 <0.000049>
13:35:33.783575 select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
<0.995399>
13:35:34.779225 pread(3,
"q\5\0\0\357%\16\0i\1\0\0\251\1\0\0\252\1\0\0R\0\250\10"..., 4096,
1478656) = 4096 <0.000058>
13:35:34.780759 select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
<0.998371>
13:35:35.779391 pread(10,
"\265\7\0\0w,\v\0qu\0\0ru\0\0\362t\0\0\1\0\346\17\0\7g "..., 4096,
123146240) = 4096 <0.000061>
13:35:35.791822 select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
<0.997185>
13:35:36.789248 pread(3,
"\314\5\0\0?2\4\0o\1\0\0\260\1\0\0\261\1\0\0R\0\240\10\1"..., 4096,
1503232) = 4096 <0.000061>
13:35:36.790505 select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
<0.998487>
13:35:37.789227 pread(10,
"\265\7\0\0\253\302\t\0\21u\0\0Au\0\0\20u\0\0\1\0\346\17"..., 4096,
122753024) = 4096 <0.000054>
13:35:37.802013 select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
<0.996968>
13:35:38.799221 pread(3,
"\313\4\0\0_F\3\0V\1\0\0\226\1\0\0\227\1\0\0R\0\250\10\1"..., 4096,
1400832) = 4096 <0.000058>
13:35:38.800765 select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
<0.998212>
13:35:39.799221 pread(10,
"\265\7\0\0w,\v\0qu\0\0ru\0\0\362t\0\0\1\0\346\17\0\7g "..., 4096,
123146240) = 4096 <0.000056>
13:35:39.811588 select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
<0.997464>
...
strace -T -tt svnadmin dump SVN > out
13:58:41.704981 select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
<0.994011>
13:58:42.699233 pread(9,
"\345\6\0\0\301\361\1\0\366\3\0\0\365\3\0\0\367\3\0\0@\0"..., 4096,
4153344) = 4096 <0.000058>
13:58:42.699562 select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
<0.999463>
13:58:43.699219 pread(10,
"\261\10\0\0M\337\2\0\344t\0\0\0\0\0\0P\271\0\0Y\0p\n\2"..., 4096,
122568704) = 4096 <0.000058>
13:58:43.699473 select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
<0.999563>
13:58:44.699228 pread(10,
"\373\6\0\0\330\205\16\0\301m\0\0/\1\0\0\300m\0\0\232\0"..., 4096,
115085312) = 4096 <0.000060>
13:58:44.699603 select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
<0.999464>
13:58:45.699258 pread(10,
"\344\6\0\0\330\320\5\0\255\223\0\0\0\0\0\0\0\0\0\0)\0p"..., 4096,
154849280) = 4096 <0.000058>
13:58:45.699512 select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
<0.999515>
13:58:46.699221 pread(10,
"\345\6\0\0u\361\1\0w\236\0\0y\236\0\0\233\236\0\0\254\0"..., 4096,
166162432) = 4096 <0.000057>
13:58:46.699518 pread(9,
"\254\10\0\0\302.\1\0`\3\0\0_\3\0\0a\3\0\0D\0\354\1\1\5"..., 4096,
3538944) = 4096 <0.000041>
13:58:46.699766 write(1, "Prop-content-length: 85\n", 24) = 24
<0.000043>
13:58:46.699937 pread(3,
"\250\10\0\0\362\256\17\0\1\0\0\0\0\0\0\0\0\0\0\0\5\0\260"..., 4096,
4096) = 4096 <0.000038>
13:58:46.700093 pread(3,
"\253\10\0\0QL\17\0\2\0\0\0\0\0\0\0\211\1\0\0\242\0\300"..., 4096, 8192)
= 4096 <0.000028>
13:58:46.700883 pread(10,
"\220\4\0\0\256\242\16\0\307z\0\0\315z\0\0\302z\0\0\1\0"..., 4096,
128741376) = 4096 <0.000038>
13:58:46.701065 pread(10,
"\220\4\0\0\4\324\16\0\265z\0\0\271z\0\0\255z\0\0\1\0\346"..., 4096,
128667648) = 4096 <0.000027>
13:58:46.701248 pread(10,
"\220\4\0\0>&\17\0Bz\0\0Az\0\0Cz\0\0\1\0\346\17\0\7f 7 "..., 4096,
128196608) = 4096 <0.000028>
13:58:46.701463 pread(10,
"\220\4\0\0\316\251\17\0pz\0\0qz\0\0oz\0\0\1\0\346\17\0"..., 4096,
128385024) = 4096 <0.000027>
13:58:46.701621 pread(10,
"\220\4\0\0$\333\17\0mz\0\0nz\0\0\215z\0\0\1\0\346\17\0"..., 4096,
128372736) = 4096 <0.000026>
13:58:46.701765 pread(10,
"\221\4\0\0\34\0\0\0\216z\0\0\215z\0\0\217z\0\0\1\0\346"..., 4096,
128507904) = 4096 <0.000026>
13:58:46.701934 pread(10,
"\221\4\0\0\344A\0\0\227z\0\0\224z\0\0\244z\0\0\1\0\346"..., 4096,
128544768) = 4096 <0.000027>
13:58:46.702117 pread(10,
"\221\4\0\0\36\224\0\0\277z\0\0\275z\0\0\304z\0\0\1\0\346"..., 4096,
128708608) = 4096 <0.000028>
Re: subversion 0.26 performance problem
Posted by cm...@collab.net.
Martin MAURER <ma...@email.de> writes:
> I got quite a strange subversion performance problem:
> i have a repository consisting of the web tree of my company.
> (the data is not important, it has been created using the backups - just
> evaluating svn at the moment)
> the repo consists of about 30.000 files in 55 revisions.
> The SVN dir has 388 MB
>
> When i start "svnlook tree" on that repo, then it starts quite ok.
> But as soon as it reaches a directory where i have about 4.000 images
> (jpg,gif) it is getting very slow (a few seconds per file).
> CPU is idle and Filesystem is not under heavy load too.
Martin, I'm sure there are several developers who would be interested
in seeing this behavior first-hand. Is your repository private? That
is, could you make a tarball of it and provide a URL? (If the
contents are private, and you trust me not to disseminate them, you
could send me the URL privately).
Secondly (which should perhaps be "firstly") -- are you able to debug
this at all? I'm not sure where to start -- maybe running svnlook
under strace or something. Or, can you play with the number of files
in that directory and see how the behavior is affected? If you cut
the number from 4000 to 2000, is the time between each file is handled
also cut roughly in half?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org