RE: Large file actual performance report; cvs use of ,v header is sometimes non-optimal.

[Bulgrien, Kevin]

> > I would have to 
> > wonder what kind of specs does the machine have?
> > 
> > He does give some of them...
> > "* Server is old (Dell PowerEdge 2300; Dual Pentium II 400 
> > MHz; 1 GB RAM,
> >      disks are SCSI RAID) but server idles with very little 
> > CPU usage."
> > 
> > Guess:
> > 3+ year old machine, working for a big contractor...
> > http://www.dell.com/content/topics/global.aspx/corp/pressoffic
> > e/en/1999/1999_02_26_rr_003?c=us&l=en&s=corp

<snip>

> > And a bit about the troubling file
> > "the repository size of the file is on the order of 315 MB."
> 
> Yes, indeed, top showed that.
> > which means that there is less than 650MB of ram left 
> > (assuming nothing else 
> > like X is running on the machine, and tmp is not a ram file 
> > system) to process 
> > the file (and  IIRC CVS copies the file to tmp first so a bit 
> > more is gone). 
> > How much swap was being used before, during and after the 
> operation???
> 
> X was not active except that the console does have a graphical login
> manager running.
> 
> Swap wasn't significantly affected.  Normal for swap is < 
> 3MB.  During the
> operations, I looked at it and do not recall exact figures, 
> but did note
> that AFAICT was not significant and was less than < 10MB if 
> at all above
> normal.
> 
> > Does this server serve anything else
> >   NFS, SAMBA, IMAP, HTTP, PostgreSQL
> 
> NFS
>   No.
> 
> Samba
>   Yes.  Load is intermittent, but rarely significant.  Some 
> developers use
>   samba shares as their working directories, but this usage 
> was handled
>   well enough by the second processor (except of course 
> considering that
>   the disk accesses would have been on the same controller as 
> the repo.
> 
> IMAP
>   No.
> 
> HTTP
>   Yes. Very light internal use.  Normal is max of two idling 
> servers with
>   no active connections.
> 
> Postgresql
>   Yes. Very light.  Supports a very lightly used application.
> 
> > It might not be eating the processors, but each of these 
> requires RAM.

This is a first commit to branch of the top of HEAD.

HEAD   = 1.26
COMMIT = 1.26.2.1

Swap here is not touched at all.  This data stays consistent through the
operation.

1: - 12:07:55 up 6 days,  1:15,  5 users,  load average: 1.40, 0.92, 0.58
Tasks: 140 total,   3 running, 137 sleeping,   0 stopped,   0 zombie
Cpu0  : 100.0% us,  0.0% sy,  0.0% ni,  0.0% id,  0.0% wa,  0.0% hi,  0.0%
si
Cpu1  :  8.8% us,  5.5% sy,  0.0% ni, 81.1% id,  0.4% wa,  0.6% hi,  3.5% si
Mem:   1034312k total,  1020576k used,    13736k free,    20724k buffers
Swap:  1044216k total,     3004k used,  1041212k free,   696876k cached

1 UID USER     RUSER    GROUP    TTY       PR  NI S   PID  PPID P %CPU
  505 username username grp      ?         25   0 R 28174 28146 0 99.9

TIME+  %MEM  VIRT  RES SWAP CODE DATA  SHR nFLT nDRT WCHAN     Flags
4:01.00 18.5  527m 186m 340m  548 161m 1072   52    0 stext     ..8...4.

COMMAND
cvs server

The top information stays basically consisent with the above.

$ df /tmp /var/tmp
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda8             2.1G  102M  2.0G   5% /tmp
/dev/sda6             2.1G  121M  1.9G   6% /var/tmp

At this point it is working completely out of RAM/virtual memory as there
is no footprint in /tmp, /var/tmp that I can see.

$ du -s /path/to/repository
491M    /path/to/repository

I am not sure how best practices and recent CVS revisions would help this
performance.  Again, there is no intent here to criticize CVS, but to
have hard numbers to help me gauge how to use this server optimally or
when to push harder for better hardware.  The server hardware is old, and
file size has a big impact.  This server has been more than adequate for
years.  Files this size have not needed to be controlled previously.
Unless we can improve on the hardware, files this size need to be
controlled some other way.

I would not mind seeing hard numbers for alternate solutions, but the
general statement that tool X just doesn't have this problem is not
particularly helpful.  That said, I have no expectation for someone
to go to the effort of finding hard numbers for me.

Kevin R. Bulgrien

This email message is for the sole use of the intended recipient(s) and may 
contain General Dynamics SATCOM Technologies confidential or privileged 
information.  Any unauthorized review, use, disclosure or distribution is 
prohibited.  If you are not an intended recipient, please contact the sender by 
reply email and destroy all copies of the original message.