info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Problems checking out & updating files: fatal signal 11; Virtual memory


From: Avi Green
Subject: Problems checking out & updating files: fatal signal 11; Virtual memory exhausted; etc.
Date: Tue, 12 Dec 2000 19:07:39 -0500

Dear CVS folk,

I'm a system admin at sputnik7.com (a streaming music site; come
visit!). Our developers use a mix of WinCVS, MacCVS Pro, MacCVS 3.0, and
the
standard Unix client.

One of our Mac developers has been having serious problems for some
time.
I've been able to generate similar errors using the Unix cvs client on
some of her files:

address@hidden CVS_FILES]$ cvs co creative/print  
cvs server: Updating creative/print
U creative/print/sputnik7_circle_stickers.eps
U creative/print/stickers.sit
cvs server: Updating creative/print/SXSW
U creative/print/SXSW/SXSW_FLYER_IMG.psd
U creative/print/SXSW/SXSW_FLYER_outline.ai
U creative/print/SXSW/SXSW_POSTER_IMG9.psd
Terminated with fatal signal 11

SERVER # find /home/cvs/cvsrep -size +100000 -ls |sort +6 # I cut some
cols
115188632 Sep 11 15:16 .../Creative/print/bigass banners/4x8banner.psd,v
119852517 Sep 11 15:09 .../Creative/print/bigass
banners/4x10banner.psd,v
119852517 Sep 11 15:15 .../Creative/print/bigass
banners/4x10_banner.psd,v
139484784 Sep 11 15:25 .../Creative/print/SXSW/SXSW_POSTER_outline.ai,v
 52609784 Sep 11 15:21 .../Creative/print/holliday cards/99/ice ice
baby-scans.psd,v

address@hidden CVS_FILES]$ cvs co
creative/print/SXSW/SXSW_POSTER_outline.ai
Terminated with fatal signal 11

address@hidden CVS_FILES]$ cvs co creative/print/"bigass
banners"            
cvs server: Updating creative/print/bigass banners
Fatal server error
Virtual memory exhausted.
U creative/print/bigass banners/4x10_banner.psd

address@hidden CVS_FILES]$ cvs co creative/print/"holliday cards/99/ice
ice baby-scans.psd"
Fatal server error
Virtual memory exhausted.
U creative/print/holliday cards/99/ice ice baby-scans.psd

address@hidden CVS_FILES]$ cvs co creative/print/"holliday cards"/99
cvs server: Updating creative/print/holliday cards/99
U creative/print/holliday cards/99/card image.psd
U creative/print/holliday cards/99/holidaypostcard-needsfonts8.ai
U creative/print/holliday cards/99/holidaypostcard-nofonts.ai
U creative/print/holliday cards/99/ice ice baby-scans.psd
cvs [checkout aborted]: end of file from server (consult above messages
if any)

address@hidden CVS_FILES]$ cvs co creative/print/"holliday cards"/99
cvs server: Updating creative/print/holliday cards/99
U creative/print/holliday cards/99/ice-cmyk.psd
U creative/print/holliday cards/99/snow.ai

address@hidden CVS_FILES]$ rm creative/print/"holliday cards"/99/ice*

address@hidden CVS_FILES]$ cvs co creative/print/"holliday cards"/99
cvs server: Updating creative/print/holliday cards/99
U creative/print/holliday cards/99/ice ice baby-scans.psd
U creative/print/holliday cards/99/ice-cmyk.psd

address@hidden CVS_FILES]$ rm creative/print/"holliday
cards"/99/ice*         

address@hidden CVS_FILES]$ cvs co creative/print/"holliday
cards"/99           
cvs server: Updating creative/print/holliday cards/99
U creative/print/holliday cards/99/ice ice baby-scans.psd
U creative/print/holliday cards/99/ice-cmyk.psd



While the above checkouts were running, I ran "top" and "vmstat 5".
According to top, cvs's resident memory usage was at 82MB or 78MB.
(I ran top twice.)  Vmstat showed my swap memory going down from 283768
to as low as 129960 and my free memory going down from 204672 to as low
as 57872:

 procs     memory            page            disk          faults     
cpu
 r b w   swap  free  re  mf pi po fr de sr s0 s1 -- --   in   sy   cs us
sy id
 0 0 22  3352  2744   0  14 14  1  5  0  1  1  1  0  0  120   59   28 
0  1 99
 0 0 28 234248 155080 0   0  0  0  0  0  0 11  0  0  0  168  107   43 
0  2 97
 0 0 28 283768 204672 0   0  0  0  0  0  0  0  0  0  0  104   81   20 
0  0 99
 0 0 28 283768 204672 0   0  0  0  0  0  0  0  0  0  0  103   79   21 
0  0 99
 0 0 28 283768 204672 0   0  0  0  0  0  0  0  0  0  0  104   76   20 
0  1 99
 0 0 28 283768 204672 0   0  0  0  0  0  0  7  0  0  0  144  141   24 
0  3 97
 0 0 28 283768 204672 0   0  0  0  0  0  0  0  0  0  0  103   76   18 
0  1 99
 0 0 28 283768 204672 0   0  0  0  0  0  0  0  0  0  0  103   76   19 
0  0 99
 0 0 28 283768 204672 0   0  0  0  0  0  0  0  0  0  0  104   81   19 
0  0 99
 0 0 28 256952 178984 0 1550 0 17 17  0  0 18  2  0  0  230 1573   67 49
17 34
 0 0 28 134976 57872  0 2655 0  0  0  0  0  0  0  0  0  740 9779 5453 46
54  0
 1 0 28 129960 71272  0 417  0  0  0  0  0  2  0  0  0 1263 6074 4603 40
36 23
 0 0 28 209096 129952 0   0  0  0  0  0  0  8  2  0  0  891  784 1055  0
12 88
 0 0 28 209088 129944 0   1  0  0  0  0  0  0  0  0  0  264  232  208 
0  3 97
 0 0 28 209096 129952 0   0  0  0  0  0  0  0  0  0  0  103   78   22 
0  1 99
 0 0 28 209096 129952 0   0  0  0  0  0  0  0  0  0  0  104   83   22 
0  0 99



I got the following using /usr/sbin/sysdef:

*
* System Configuration
*
  swap files
swapfile             dev  swaplo blocks   free
/dev/dsk/c0t0d0s1   32,1      16 265664   1504
*
* Tunable Parameters
*
 7806976        maximum memory allowed in buffer cache (bufhwm)
    5962        maximum number of processes (v.v_proc)
      99        maximum global priority in sys class (MAXCLSYSPRI)
    5957        maximum processes per user id (v.v_maxup)
      30        auto update time limit in seconds (NAUTOUP)
      25        page stealing low water mark (GPGSLO)
       5        fsflush run rate (FSFLUSHR)
      25        minimum resident memory for avoiding deadlock (MINARMEM)
      25        minimum swapable memory for avoiding deadlock (MINASMEM)
*
* Utsname Tunables
*
     5.6  release (REL)
...
   SunOS  system name (SYS)
Generic_105181-05  version (VER)
*
* Process Resource Limit Tunables (Current:Maximum)
*
ffffffff:fffffffd       cpu time
ffffffff:fffffffd       file size
ffffffff:fffffffd       heap size
ffffffff:fffffffd       stack size
       0:7ffff000       core file size
ffffffff:fffffffd       file descriptors
       0:  800000       mapped memory



I looked through cvshome.org and the net and found a couple of postings
(though no FAQs or docs) suggesting that the problem was with memory
usage.  So I went through the appropriate docs on cvshome.org. (I've
included them below in case anyone's interested.)

Apparently CVS wasn't designed for huge files (especially the size of
graphic files today!) and suffers from some memory inefficiencies on
checkout and diff operations.  The apparent solution for such files is
either not to use CVS or to throw hardware at the problem.  Is this in
fact the case, or is there a fix?  I'm using version 1.10, which of
course isn't the MOST recent.

Any help would be appreciated.

Thanks again,
Avi

======================================================
= Avi Green :-) avi at sputnik7.com (-: 212 217-1147 =
========  Unix SysAdmin & System Specialist  =========
=============  http://www.sputnik7.com  ==============
===== Netcasting Music, Videos, Film & Anime 24/7 ====

following:

Server requirements:
(http://www.cvshome.org/docs/manual/cvs_2.html#SEC27)

The first area of big memory consumption is large checkouts, when using
the CVS server. The server consists of two processes for each client
that it is serving. Memory consumption on the child process should
remain fairly small. Memory consumption on the parent  process,
particularly if the network connection to the client is slow, can be
expected to grow to slightly more than the size of the sources in a
single directory, or two megabytes, whichever is larger. 

Multiplying the size of each CVS server by the number of servers which
you expect to have active at one time should give an idea of memory
requirements for the server. For the most part, the memory consumed by
the parent process probably can be swap space rather than physical
memory. 

The second area of large memory consumption is diff, when checking in
large files. This is required even for binary files. The rule of thumb
is to allow about ten times the size of the largest file you will want
to check in, although five times may be adequate. For example, if you
want to check in a file which is 10 megabytes, you should have 100
megabytes of memory on the machine doing the checkin (the server machine
for client/server, or the machine running CVS for non-client/server).
This can be swap space rather than physical memory. Because the memory
is only required briefly, there is no particular need to allow memory
for more than one such checkin at a time. 

Resource consumption for the client is even more modest--any machine
with enough capacity to run the operating system in question should have
little trouble.




Other useful references:

* Resource Consumption          http://www.cvshome.org/docs/inforesconsum.html

* System Requirements           http://www.cvshome.org/docs/infosysreq.html



reply via email to

[Prev in Thread] Current Thread [Next in Thread]