Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Actually, after further diagnosing the problem, I'm not sure if it is happening on updates or commits. I personally couldn't replicate it while sitting at the guy's machine, but after we fixed his OTHER cvs problem and he started updating and committing (user error - he didn't know the difference between "add" "update" and "commit"), someone informed me that the processes had, again, begun to eat the machine for lunch. After 10-20 minutes of taking up (roughly) 25% of the processor each, I had to kill them. We're talking about 2-50k files here. Looks like he ran an update or a commit dealing w/ a binary file. I yelled at him for including this specific binary file, because it was basically a user preferences file, but none the less, it happened. Of the 4 temp directories generated for the 4 screwed processes, three only had a few CVS control files in them, namely "Repository" "Entries" and "Root." The 4th had the binary file mentioned earlier. Would you suggest I try 2.1.1 even though it was released BEFORE 2.0.8? Thanks again for all your help, Chavous Camp ----- Chavous P. Camp <ccamp at scconsultants.net> Member/Principal Salter & Camp Consultants, Ltd. Co. 1213 Lady St. Suite 205 PO Box 11285, Columbia, SC 29201 (803)461-8970 fax 803.461.8973 Computer and Information Architects ------------------------------------------- -----Original Message----- From: cvsnt-bounces at cvsnt.org [mailto:cvsnt-bounces at cvsnt.org] On Behalf Of Tony Hoyle Sent: Monday, August 04, 2003 6:45 AM To: cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook Subject: Re: [cvsnt] Win2k Processor Usage Spirals Out of Control On Mon, 4 Aug 2003 06:28:42 -0400, "Chavous P. Camp" <ccamp at scconsultants.net> wrote: >The problem is it doesn't go away after time. They turn into energizer >bunny processes. And, really, we aren't committing that large of files. >They are all text files (source code) less than 100k. Doing a quick >sample, the largest ,v file I see is 54k. Okay, wait a sec. Some folks >uploaded some binary files running around 100-150k, but still - nothing >in the megabyte range. Our entire repository is only 12.5M and only has >1800 files, for an average of somewhere around 7k per file, if I'm >calculating correctly. That shouldn't be a problem... you can get away with a few MB befire you'll notice any load problem even on a smallish machine. It's 10s and 100s of MB that start to scale badly. >The other thing is, the client has LONG disconnected while the processor >is still spiraling... The only other thing I can think of is an old sserver problem that was fixed a few versions ago. The current devel version is even more bulletproof so I can merge those changes into the release if it's still causing a problem. >At first I thought it was the atomic commits, but I turned those off >long before posting to the list. THEY caused other problems. :) > Atomic commits don't work particularly well... They'll not be needed soon, though (hopefully). Tony _______________________________________________ cvsnt mailing list cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt https://www.march-hare.com/cvspro/en.asp#downcvs