Re: CVS Performance Related issue.

[Rachel Burns]

Just looking at the RSS footprint of each CVS process it is clear you
are consuming a lot of memory. If you say you have 80+ users always logged
in, then with an avg process size ~60MB, you are talking about 4800MB, 4GB+.
You have adequate swap and plenty of CPUs.

Seems like you have fairly large file sizes that causes the CVS server 
process footprint
to be large. Do you notice the CPU spike when cvsupd starts copying 
(every 30 mins) ?

We have been using the WANdisco CVS Replicator solution for our 
replication and
performance needs. We previously had 100+ concurrent cvs users connected 
to a central server, now we have 2 sites with roughly 60-40 split. That 
cut down the load on our central
server quite a bit. Also another nice side effect has been reduced 
number of CVS
processes when users conflicts on same locks. WANdisco has an in-memory 
lock service
that avoids forking CVS processes  needlessly while locks are being held 
elsewhere.

Maninder Singh(SDG) wrote:

> Hi All,
>         I'm not sure, if this problem is exactly related to cvs, but
> please advise..
>
>    We are facing a problem related to the performance of our CVS
> server. The system is a Quad Processor, Server Class machine with 4 GB
> of RAM. We have a large number of cvs users on this system (more than 80
> CVS users are connected concurrently most of the times).
>
>         We are also running cvsup to synchronize two ( 2 ) slave
> machines in remote locations on a very short interval of 30 mins; which
> is unavoidable.
> The following are the load statistics of the machine using the uptime
> command.
>
> # uptime
>  3:49pm  up 22 days, 13 min,  5 users,  load average: 4.52, 4.26, 4.24
>
> The load shoots upto 5.69 or more at times.
>
> Output from the top command is as follows:
> # top
> CPU0 states:  4.4% user,  1.3% system,  0.0% nice, 93.1% idle
> CPU1 states:  6.0% user,  5.4% system,  0.0% nice, 87.4% idle
> CPU2 states: 16.3% user,  1.1% system,  0.0% nice, 81.4% idle
> CPU3 states: 82.1% user,  1.1% system,  0.0% nice, 16.1% idle
> Mem:  3946640K av, 3883476K used,   63164K free,       0K shrd,   87336K
> buff
> Swap: 6193120K av,  192300K used, 6000820K free                 2487524K
> cached
>
>  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
> 10721 xxxx    25   0 72236  70M   940 R    89.2  1.8   1:32 cvs
> 10702 xxxx    18   0 53356  52M  1092 S    13.8  1.3   0:08 cvs
> 10722 xxxx   17   0 61000  59M  1160 S    11.3  1.5   0:08 cvs
> 10701 xxxx    15   0 76052  74M   880 S     9.4  1.9   0:03 cvs
>
> 8115 root      15   0 33256  32M 23068 D     6.5  0.8  10:11 cvsupd
>
> Could it be that, cvs is taking too much memory hungry (as I can make
> out from the above stats)? Do we need to upgrade on RAM or is there
> still a better solution to this problem?
>
>
> Regards,
>
> Maninder Singh
>
> Member-SDG(SCM)
>
>
> _______________________________________________
> Info-cvs mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/info-cvs
>
>