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: Thu, 27 Feb 2003 18:09:41 -0800

This is a follow up with some more observations:

While several of my build processes were running, I was monitoring the CVS
server with 'top'.  I noticed a strange occurrence with two of cvs processes
that were currently executing a log command - both processes grew to consume
nearly all available memory (in my case 512MB).  While this was occurring,
the cvs clients associated with these growing cvs processes started dumping
the 'waiting for blahs lock' messages to stdout.  This went on for about 15
minutes before the log commands completed.  Does anyone know if this is
normal behavior?

BTW, in case you're curious, the log command is running against a source
tree with ~1.5 GB of mixed binary and text source files.  I think the
biggest binary file is ~30MB.

Regards,

-- Ian MacDonald


-----Original Message-----
From: MacDonald, Ian [mailto:address@hidden 
Sent: Thursday, February 27, 2003 12:10 PM
To: 'address@hidden'
Subject: Lock contention executing cvs log


Hi Folks, 
I'm sorry if this posting might appear twice.  I first posted this to the
NNTP group gnu.cvs.help but was not sure my posts were actually making it.
Here's my problem: 
We have an automated build environment (CruiseControl) running on multiple
hosts that poll for changes in a cvs repository using the cvs log command.
We are seeing a
problem that seems to be resulting in an inordinate amount of time executing

the log command. 
When to two or more of the hosts are executing "cvs -q log -N -d upperdate >

Lowerdate -b" on the same module they seem to get stuck in a lockstep mode
of 
waiting for each others locks with each module taking upwards of a 
minute.  For our respository this adds up to 30 minutes to each build cycle
scanning for changes. 
Shouldn't cvs simply be using "read" locks while executing the log command? 
If that's the case, why is there a contention for the "read" locks?  Perhaps
there is a write lock getting created? 
Any assistance would be appreciated. 
Thanks, 
-- Ian MacDonald 




reply via email to

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