info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Lock contention executing cvs log


From: MacDonald, Ian
Subject: RE: Lock contention executing cvs log
Date: Fri, 28 Feb 2003 11:13:43 -0800

(Hopefully this time at plain-text) - Sorry again

Thanks Larry,

Sorry for the MIME post.  I realized that I forgot to turn it off after sending it (and you can't un-send a message).

Not sure if you saw my follow up.  But I'm now thinking that the lock contention is not the source of my performance problems, just a side effect.  My theory is that the CVS processes are effectively serializing themselves by virtue of using up most of the available memory while they operate on a particular directory.  When a large cvs process releases enough memory for another cvs process to operate freely, the new process runs into several of other cvs processes which were also now trying to do the same thing which is acquire a read lock on the next directory.  Another clue is that I can start several build cycles on different hosts at random start times (15-20 minutes apart), but they eventually become synchronized and all finish within a few seconds of each other.

I guess my question now is why the cvs processed grow so large.  Can you characterize how cvs should behave with respect to memory allocations when performing a log command over a set of directories?

Regards,

-- Ian MacDonald

-----Original Message-----
From: MacDonald, Ian [mailto:address@hidden]
Sent: Friday, February 28, 2003 11:02 AM
To: address@hidden
Subject: RE: Lock contention executing cvs log


Thanks Larry,
Sorry for the MIME post.  I realized that I forgot to turn it off after sending it (and you can't un-send a message).
Not sure if you saw my follow up.  But I'm now thinking that the lock contention is not the source of my performance problems, just a side effect.  My theory is that the CVS processes are effectively serializing themselves by virtue of using up most of the available memory while they operate on a particular directory.  When a large cvs process releases enough memory for another cvs process to operate freely, the new process runs into several of other cvs processes which were also now trying to do the same thing which is acquire a read lock on the next directory.  Another clue is that I can start several build cycles on different hosts at random start times (15-20 minutes apart), but they eventually become synchronized and all finish within a few seconds of each other.

I guess my question now is why the cvs processed grow so large.  Can you characterize how cvs should behave with respect to memory allocations when performing a log command over a set of directories?

Regards,
-- Ian MacDonald



> -----Original Message-----
> From: address@hidden [mailto:address@hidden]
> Sent: Friday, February 28, 2003 8:13 AM
> To: address@hidden
> Cc: address@hidden
> Subject: Re: Lock contention executing cvs log
>
>
> MacDonald, Ian writes:
> >
> > MIME-Version: 1.0
> > Content-Type: multipart/mixed;
> > boundary="===============91921517666352637=="
>
> Please do not send MIME and/or HTML encrypted messages to the
> list. Plain text only, PLEASE!
>
> > Shouldn't cvs simply be using "read" locks while executing the log
> > command?
>
> It should, and it is.
>
> > If that's the case, why is there a contention for the "read" locks?
>
> Because you need an exclusive lock to create a read lock. 
> The exclusive lock is only held for a very short time (just
> long enough to create the read lock), but it's still possible
> for there to be contention for it.
>
> -Larry Jones
>
> I must have been delirious from having so much fun. -- Calvin
>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]