Re: CVS Performance

[Eric Siegerman]

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.        address@hidden
|  |  /
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.