I want to work on improving the performance of FSFS on a NFS file
system. I'm looking for feedback on an approach and to find out if
others are already working on this.
The first observation is that there are a large number of small
open-read/write-close operations. Some files will be opened more than
once per file committed (see below).
The first thought is to work on caching some of these: "node.0.0" is
the node revision, and "props" contains the revision properties. The
"changes" file is always(?) appended to, so we might be able to keep
it open and keep appending to it. The tricky bit is that the httpd
will close at some point and an a fresh one will end up advancing the
transaction. This implies that the disk version must be kept up to
date.
An alternative/additional thought would be to move the transactions
directory to local disk so that the OS can cache more aggressively.
This would require network load balancers to always direct the same
client to the same server.
A completely separate idea is to work on caching revision files on
local disk (so the full text version doesn't have to be regenerated
repeatedly). The import case below does none of this, but a typical
commit would reconstruct the previous revision of every file. This
takes advantage of the fact that revisions never change after they are
written.
Here are the top open calls by name/flags for a 133 file import:
131 /svnrepo/db/transactions/39-18.txn/node._0.0.children", flag=10
133 /svnrepo/db/transactions/39-18.txn/next-ids", flag=129
133 /svnrepo/db/transactions/39-18.txn/next-ids", flag=18
133 /svnrepo/db/transactions/39-18.txn/rev", flag=130
133 /svnrepo/db/transactions/39-18.txn/rev-lock", flag=6
134 /svnrepo/db/transactions/39-18.txn/node._0.0", flag=129
296 /svnrepo/db/transactions/39-18.txn/changes", flag=142
306 /svnrepo/db/transactions/39-18.txn/props", flag=133
596 /svnrepo/db/transactions/39-18.txn/node.0.0", flag=129
Feedback is much appreciated.
Thanks,
-Dan Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 14 00:16:58 2007