> > 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.
