On Thu, Jan 04, 2001 at 04:51:23PM -0600, Cheryl Tipple wrote:
> It appears we have a performance problem within our CVS system.
> [CPU, network bandwidth, filesystem access path, RAM, swap are
> all far from saturated]
>
> Can anyone tell me if there are any
> [...] tests I can run to trace this problem? We are also
> going to try a network sniffer from our end to identify where the data
> is moving.
How about physical disk I/O? You don't say which operations are
causing you trouble, but update and commit both do a lot more
disk I/O than one would naively expect -- they do locking by
creating temporary directories (because mkdir() is atomic, I
presume):
1. create a lock directory in each repository directory to be
operated on, recursively all the way down
2. do the operation
3. delete all the lock directories
Note that:
- This is three recursive passes over the affected subtree, NOT
a single pass in which all three operations are done on each
directory as it is visited
- The per-directory progress messages are all printed during
step 2; steps 1 and 3 are silent.
To find out how much of the slowness is network-related, remove
the network from the equation: try doing the same operations
locally (ie. non-client/server) on the server machine. To do
this, set CVSROOT (or the value of the prefix -d option) to the
unadorned absolute pathname of the repository, ie. with no access
method specified. (Even if you don't want to give accounts to
the developers, the admin can do a checkout or two for testing --
or even commits, on a scratch copy of the repository.)
Good luck.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont. [EMAIL PROTECTED]
| | /
Interviewer: You've been looking at the stars all your life:
Is there anything in astrology?
Arthur C. Clarke: It's utter nonsense. But I'm a Sagittarius,
so I'm naturally skeptical.
_______________________________________________
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs