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.
We are having an ongoing issue with CVSNT version 2.5.03 (Scorpio) Build 2382 where CVS transactions become extremely slow if more then a couple of people are hitting the server at once. The server has Windows Server 2003 Standard with Service Pack 2, dual dual-core 3.0 GHz Xeon processors, 4GB of ram, two 1GB NICs (bound together), and EMC Symmetrix SAN storage. There are five repositories on the server, of which three are in active development. The largest repository is 5GB. The largest module within that repository is 1.15GB. When checked out that module is 580MB. We have about 70 people working on this project, 6 of which are in a remote office connected by a 15Mb T3. DNS has been verified to be working correctly for all clients and the server. During the times that CVS is responding slowly, processor usage is rarely above 5%, memory usage is at about 1GB sometimes up to about 1.5GB depending on what the transactions are doing, disk queue length is typically 0 to 1, network usage is at about .5%, and local checkouts on the server it take just as long as from a client pc. I have tried having everything run on local disks instead of the SAN; all transactions ran slower. Removing on access virus scanning helped improve speeds by about 20% for a single isolated transition (no one else on the server), but CVSNT still responded slowly when multiple people were using the server. The problem seems to be most evident when more then one connection from the remote office is established. CVS seems to be responding to all cvs.exe processes at the same speed as the slowest process. When this problem occurs, the only way to clear it up seems to be to kill most of the cvs.exe processes on the server. At that point the What am I missing? Does anyone have any ideas of what could be causing these slowdowns? Any help would be appreciated. Thanks, John