----------- From Andrew Weston, Adacel Pty Ltd -----------
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 9026
Hi all,
I must apologise for a summary that is long overdue (2 months).
I enquired about problems we had here with users not having enough
"space" to make a program (original request appended).
A big Thank you to:
paul.ottaway_at_eurocontrol.be (Paul Ottaway)
alan_at_nabeth.cxo.dec.com (Alan Rollow)
Knut.Hellebo_at_nho.hydro.com (Hellebo Knut)
jst_at_atb.ch (Juerg Staub)
piumarta_at_prof.inria.fr (Ian Piumarta)
szgyula_at_skysrv.Pha.Jhu.EDU (Gyula Szokoly)
stuart.davidson_at_eurocontrol.be (Stuart Davidson)
In brief:
1. Swap can easily be eaten up and my estimates on swap required could
easily be wrong.
2. swapon -s and vmstat could give me some stats. Good to run these
when the make is in progress.
3. The -pipe option in the compile will increase the memory/swap
required - we were using this option.
4. Check into setting shell limits for virtual memory.
Further:
One reason for the delay is that the user has not re-tried the compile
but moved onto another project. I did add some swap space and the only
comments I am hearing is more related to the load on the machine.
We also observed that the same C++ files that has previously been
compiled on the DG (using g++) and Sun (SPARCWORKS C++), when compiled
with CXX seemed to create files between 2 and 5 times larger. - has
anyone else observed this. From this we assume that the DEC compilers
might also be resource hungry.
A big thankyou to all who responded to my query, and apologies once
again for a late summary.
Thanyou,
Andrew Weston
SPECIFIC RESPONSES:
---------------------------------------------------------------------
From: paul.ottaway_at_eurocontrol.be (Paul Ottaway)
We had this problem and it came down to not enough swap.
---------------------------------------------------------------------
From: alan_at_nabeth.cxo.dec.com (Alan Rollow)
Various shells put additional limits of virtual memory use for
both stack and data size. For the shell you are using, check
the manual page to see if it has any built-in command for
looking and changing the limits. For the C-shell you want
limit and unlimit. While the data limit is likely to be
large enough for most things, the stack limit may only 2 MB
which could stress some applications.
---------------------------------------------------------------------
From: Knut.Hellebo_at_nho.hydro.com (Hellebo Knut)
You could try doing the compile in one window and run a continuous 'vmstat'
in another to see if memory is exhausted during the compilation process.
This is unfortunately not a solution for you but can be an indication on
what's going on.
---------------------------------------------------------------------
From: jst_at_atb.ch (Juerg Staub)
in csh: ( if you do not use csh, do man `yourshell`,
and look for limits )
limit stacksize unlimited
limit datasize unlimited
will set stacksize and datasize to the hardlimits ( limit -h )
and yor problem will go away.
---------------------------------------------------------------------
From: piumarta_at_prof.inria.fr (Ian Piumarta)
Not necessarily. 256Mb of VM looks like it would be adequate for most
purposes, but a large C++ compilation with the "-pipe" flag on could easily
eat it up. (The "-pipe" runs many stages of the compiler simultaneously,
piping the output from stage N directly into stage N+1 and therefore avoiding
the temporary file in the middle.)
The VM usage will also be much more severe if your /tmp directory is
allocated as tmpfs -- i.e. it is a memory file system in the swap space.
You could try several things:
1) run "top" (or "monitor", or somesuch) to see exactly how much VM is
being used
2) take out the -pipe from the compiler flags
3) check if you're using default swap allocation (the file
/sbin/swapdefault will exist). If so, try switching it off which
will (effectively) give more VM to your processes. To do this you
rename the /sbin/swapdefault file to something else and reboot.
4) add more swap space from an unused disk partition using the "swapon"
command
5) redirect the compiler's temporary files (which may be built even if
-pipe is in use) by setting TMPDIR to point to somewhere else.
---------------------------------------------------------------------
From: szgyula_at_skysrv.Pha.Jhu.EDU (Gyula Szokoly)
/usr/sbin/swapon -s
will answer this question. Check also the user limits *'limits in C-shell,
I think ulimit in ksh).
---------------------------------------------------------------------
From: stuart.davidson_at_eurocontrol.be (Stuart Davidson)
cxx and ld can eat resources... some of our compilation environments
are configured with 600MB swap!
Try something simple while the compiling to see resources being consumed:
csh> while (1) ; vmstat ; swapon -s
end
You may need to add more swap space.
Ensure that your resource limits for stack and data are increased,
see limit in csh man page and ulimit in ksh and sh man pages.
Also make sure TMPDIR is pointing to somewhere with sufficient space,
see cxx man page.
---------------------------------------------------------------------
ORIGINAL QUESTION:
---------------------------------------------------------------------
Dear all,
A user here tried to compile a program using make and received the
following error:
% make
rm -f track.o
CPP_CC=cxx dc++ -dcpp_debug_object_old -w0 -g -Dexplicit= -DTARGET_OS=180
-DTARGET_COMPUTER=185 -DDEBUG -pipe -I/usr/include/cxx -I.
-I/projects/act/devel_dec/src/include -I/projects/act/devel_dec/src/eh_include
-I. -I/usr/local/port/include -I/opt/uimx2.6/include
-I/usr/local/gen_comp/include -I/usr/local/gen_comp/edh_include -c track.cc
Fatal: An attempt to allocate memory failed.
dc++: Error: cxx failed.
*** Exit 1
Stop.
We were wondering if this is a C++ compiler problem, lack of physical
memory and/or lack of swap space.
I have argued that since swap is more than 4 times the physical memory,
that adding more will not resolve this problem. Am I correct.
For those who require more details:
We are using DU 3.2c with CXX packages:
CXXBASEA510 installed DEC C++ (cxx) for Digital UNIX
CXXLIBA510 installed DEC C++ static class libraries
CXXMANA510 installed DEC C++ manual pages: cxx, demangler and library
routines
CXXOLDA510 installed DEC C++ old packages: oldc89 and ild
CXXSHRDA306 installed DEC C++ Class Library, Run-Time Support
Machine is DEC Alpha 3000 model 700 turbochannel (server).
We have 64MB physical memory (as seen from the following uerf extract:
OS EVENT TYPE 300. SYSTEM STARTUP
SEQUENCE NUMBER 0.
OPERATING SYSTEM DEC OSF/1
OCCURRED/LOGGED ON Mon Feb 20 18:59:36 1995
OCCURRED ON SYSTEM video
SYSTEM ID x00060004 CPU TYPE: DEC 3000
SYSTYPE x00000000
MESSAGE Alpha boot: available memory from
_0x7dc000 to 0x4000000
Digital UNIX V3.2C (Rev. 148); Mon
_Feb 20 18:57:34 EST 1995
physical memory = 64.00 megabytes.
available memory = 56.14 megabytes.
using 238 buffers containing 1.85
_megabytes of memory
tc0 at nexus
Whilst root (/) and /usr filesystem are Advance Filesystems, we accepted
the default of putting swap in usr domain (at least I thought I selected
the default option), which seems to be using b partition of the disk
according to /etc/fstab:
# fgrep swap /etc/fstab
/dev/rz0b swap1 ufs sw 0 2
The b partition has approximately 260MB as seen from the disklabel
extract:
# disklabel -r /dev/rrz0a
# /dev/rrz0a:
type: SCSI
disk: rz26
label:
flags:
bytes/sector: 512
sectors/track: 57
...
8 partitions:
# size offset fstype [fsize bsize cpg]
a: 131072 0 ADVfs # (Cyl. 0 - 164*)
b: 523776 131072 unused 1024 8192 # (Cyl. 164*- 820*)
c: 2050860 0 unused 1024 8192 # (Cyl. 0 - 2569)
d: 512 654848 LSMsimp # (Cyl. 820*- 821*)
e: 552548 945764 unused 1024 8192 # (Cyl. 1185*- 1877*)
f: 552548 1498312 unused 1024 8192 # (Cyl. 1877*- 2569*)
g: 1395500 655360 ADVfs # (Cyl. 821*- 2569*)
h: 838444 1212416 unused 1024 8192 # (Cyl. 1519*- 2569*)
I will summarise if I receive any replies.
Thankyou,
Andrew Weston
(Network Adminstrator)
Note: Any comments I may make are not necessarily those of my employer.
+-------------------------------------------------------------------------+
| Adacel Pty Ltd, 250 Bay street Brighton Victoria 3182 Australia |
| email: andreww_at_adacel.com.au ph: +61 3 9596-2991 fax: +61 3 9596 2960 |
+-------------------------------------------------------------------------+
Received on Fri Sep 13 1996 - 06:16:44 NZST