RE: svn log slowness

>Is it possible that your server is I/O bound? Logs are stored in
>revprops, one per revision. So if you're pulling the history for a
>large range of revisions, you're doing a lot of access on many small
>files - some filesystems are very poor in this usage scenario.

Just recording some more info for posterity: yes, it seems to be largely IO bound. This became apparent during some experiments, where we put the FSFS repository on a local disk instead of on the NFS-mounted netapp. It improved svn log speed by more than 50%:

For our big file with 5500 revisions over https (SvnPathAuthz off)
- NFS-mounted netapp: ~3m20s
- local disk: ~1m30s
Still a long way from the 3-5 seconds we had with CVS, but it's already a big improvement.

Unfortunately, this is not a viable production option for us (needs to be on the netapp, to have all the high-availability and backup options available). But it prompted us to further investigate IO optimization options, configuration of the netapp, NFS mount options, ... I'll post here if we have any progress with these.

In any case, it made me think that packing revprop shards (as was discussed here some time ago) could make a big difference for svn log with FSFS. Switching to BDB might also help a lot, but unfortunately that's also not really possible for us currently, because the available Solaris binaries of SVN don't include support for BDB (we've checked CollabNet and sunfreeware). And we don't really have the experience nor time to build it from source.

Is there any specific reason why the CollabNet binary for Solaris doesn't include BDB support? Is it just because FSFS is the default, and the easiest for maintenance?

Regards,
Johan

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2151012

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-05-09 21:57:45 CEST