huge memory allocation
Julie A. Levell
julie at levell.austin.ibm.com
Fri Mar 15 05:00:10 AEST 1991
In article <1289 at dkunix9.dk.oracle.com> bengsig at dk.oracle.com (Bjorn Engsig) writes:
>Article <1991Mar10.180433.24685 at nrcnet0.nrc.ca> by ng at cfd.di.nrc.ca says:
>|According to what I've been told by the IBM tech hot line (from Toronto,
>|Canada), all those User Characteristics (quotas) of SMIT are for future
>|expansion only; none of them are currently enforced. I wish they are wrong.
>They are (at least on 3.1.1 (== 3003 update)):
>script done on Tue Mar 12 12:24:22 1991
>--
>Bjorn Engsig, ORACLE Corporation, E-mail: bengsig at oracle.com, bengsig at oracle.nl
No, some of the limits are enforced and some aren't (but stay tuned).
Anyway, I've include a note here that talks about how /etc/security/limits
is used. It's very primative, but I would appreciate your comments.
mail julie at aixwiz.austin.ibm.com
Semi-long note follows:
This note will discuss the use of the limit values in /etc/security/limits.
I'll explain it how I understand it.
There are six default limits in /etc/security/limits:
default:
fsize = 2097151
core = 2048
cpu = 3600
data = 131072
rss = 65536
stack = 8192
These values are used as default settings when a new user is added
to the system. They can be changed when the user is added (mkuser)
or after the user is created (chuser). At login time, these values will
be used to set the user's/process limits.
ulimit (a builtin in all the shells: the ksh, bsh and csh) can be used to look at,
and change these values (if you have the privledge to change the hard limit).
There are two values that are shown with ulimit, the SOFT limits and the HARD limits.
I'll show some examples of ulimit output.
SOFT limits (also called CUR in some cases):
[julie at levell] /u/julie$ ulimit -a (or ulimit -Sa)
time(seconds) 3600
file(blocks) 2097151
data(kbytes) 13073
stack(kbytes) 32768
memory(kbytes) 32768
coredump(blocks) 2048
HARD Limits (also called MAX limits);
[julie at levell] /u/julie$ ulimit -Ha
time(seconds) unlimited
file(blocks) 2097151
data(kbytes) 245244
stack(kbytes) 248556
memory(kbytes) unlimited
coredump(blocks) unlimited
These are my values as root:
[root at levell] <pts0> /> ulimit -a
time(seconds) 3600
file(blocks) 2097151
data(kbytes) 131072
stack(kbytes) 32768
memory(kbytes) 32768
coredump(blocks) 2048
[root at levell] <pts0> /> ulimit -Ha
time(seconds) unlimited
file(blocks) 2097151
data(kbytes) 228860
stack(kbytes) 130556
memory(kbytes) unlimited
coredump(blocks) unlimited
The SOFT limits can be increased up to the HARD limits, but to increase the HARD limits
you need priviledge.
I'll explain each of the values and how it is maintained and/or enforced.
Most of the following information is from the setrlimit(), getrlimit() file
and Beto Appleton. The RLIMIT_XXXX definitions come from the setrlimit system
call. The units mentioned are the ones that are used to set limits with
setrlimit.
Ex. If you were using setrlimit() to set the fsize then you would send the
value in bytes, but if you were using ksh builtin ulimit you would specify the
value in 512-byte blocks.
There is also a ulimit system call, that the shell builtins call. The ulimit
I will use in this note is a reference to the shell builtin ulimit.
----------------------------------------------------------------------------------
fsize = 2097151 (units in 512-byte blocks in /etc/security/limits, and ulimit)
RLIMIT_FSIZE The largest size, in bytes, of any single
file that can be created.
This value is a limit that the kernel will enforce on a user process.
Which means a user cannot create a file greater than their soft limit unless
they change their file limit with a "ulimit -Hf" call.
The largest size any file can be created is 2147483136 bytes.
----------------------------------------------------------------------------------
core = 2048 (units in 512-byte blocks in /etc/security/limits, and ulimit)
RLIMIT_CORE The largest size, in bytes, of a "core" file that may
be created.
This limit is maintained by the kernel and it will not allow a user
to create a core file larger than the set SOFT limit. Actually, the system
will use the minimum value of the core and fsize SOFT limit.
----------------------------------------------------------------------------------
cpu = 3600
RLIMIT_CPU The maximum amount of CPU time (in seconds) to be used
by each process.
This limit is set (a call is made to setrlimit() by getty) and can be
changed, but is not enforced by the kernel. This value may be checked
by application code, user code, etc, but the kernel will not enforce this
value. In other words, if a process passes it's SOFT CPU time limit, the
kernel will NOT send a SIGXCPU signal to the offending process
(as stated in the documentation, an apar will be written). The kernel will
let processes run as long as they want. So this value can be misleading.
I don't know of any applications that use this value at this time.
----------------------------------------------------------------------------------
data = 131072 (units in 512-byte blocks in /etc/security/limits, and
kbytes in ulimit)
RLIMIT_DATA The maximum size, in bytes, of the data segment for a
process; this defines how far a program may extend its
"break" value with the sbrk() system call.
Data and stack are tied together. They exist in Segment 2, and together
they can never be ~>256meg. This value is actually larger, but 256meg is a
good number to use. You can use the shell ulimit to increase the SOFT/HARD
limit for either data or stack, but the HARD limits can never cross. When
they talk about the brk and sbrk they are talking about system calls that
set the breakpoint value up to the CUR (SOFT) limit. sbrk moves the breakpoint
up and down with an increment value. malloc() calls sbrk.
Segment 1
-----------------
- -
- -
- -
- TEXT - ---> Also called Text Segment
- -
- -
- -
-----------------
Segment 2
-----------------
- ublock - ---> user information
- -
-----------------
- RED ZONE - ---> The RED ZONE is ?????
-----------------
- -
- -
ST---> - Stack Top pointer
- Stack - You can only access to the CUR value (or SOFT limit)
- Space -
CUR ***************** ---> u.ulimit[CUR].stack (Can only move CUR up to MAX)
- -
MAX -###############- ---> u.ulimit[MAX].stack
- -
- HOLE -
- -
MAX -###############- ---> u.ulimit[MAX].data
- -
- Unused memory -
- -
- -
CUR ***************** ---> u.ulimit[CUR].data (Can only move CUR up to MAX)
- - -
sbrk--> - - sbrk can't go past CUR. Any access above sbrk will give
- malloc'd - - a segmenation violation (SIGSEGV).
- space - -
----------------- - This is the the
- initialized & - - Data Segment
- unitialized - -
- variables - -
- and constansts- -
----------------- -
So, this is how the kernel sees it. The user can raise their HARD/SOFT data or
stack values with the shell ulimit or setrlimit system call.
The kernel will not let the MAX's overlap.
The kernel loader will set the initial sbrk value after it "loads" the
initialized and unitialized variables, but it cannot set the sbrk value past
the CUR (SOFT). The user (or parent process) must set the HARD/SOFT limits
higher if more space is needed before the process is exec'd.
A good example of all of this is a user that uses the ksh. The user can
increase the SOFT limit (up to the HARD limit) of the ksh (with the shell
builtin ulimit) before they run a program, because the ksh will be the
parent process (it will exec the program) and the program will inherit
these limits from the parent process, in this case, the ksh.
With DATA, you might have to lower your STACK value to be able to raise
your DATA limit. There is a possiblity that a user could kill themself
by lowering their STACK limit lower than what they have already
allocated on the stack, and then try to use it, getting a SIGSEGV.
----------------------------------------------------------------------------------
stack = 8192 (units in 512-byte blocks in /etc/security/limits, and
kbytes in ulimit)
RLIMIT_STACK The maximum size, in bytes, of the stack segment for
a process. This defines how far a program's stack
segment may be extended.
A process can access it's stack only up to the SOFT limit.
----------------------------------------------------------------------------------
rss = 65536
RLIMIT_RSS The maximum size, in bytes, to which a process's
resident set size may grow.
This limit is NOT enforced by the kernel. The kernel will not check
this value for a process. It will let the process use as much memory as
it needs to run with, and it will not kill a process if it reaches it's
SOFT limit. The kernel will only start killing processes if system wide
paging space gets very low, and that's after it has sent a SIGDANGER signal
(init will catch this signal and send a warning message to the console).
This happens when the system only has about 2meg of free paging space,
and soon after this it will start killing the largest process utilizing
virtual memory.
----------------------------------------------------------------------------------
So when a user logs in, their SOFT/HARD limits are set. SOFT limits can only be
increased up to the HARD limits, and only users with special priviledge can
increase their HARD limits.
I hope this clears up some of the questions, but I am open to comments on this.
Thanks,
Julie Levell
--
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
Julie A. Levell IBM Advanced Workstation Division Austin, Texas
Internet: julie at aixwiz.austin.ibm.com IBM VMNET: JULIEL at AUSVMQ
DeskNet: 4C-29/994 SpeakNet: 823-5178 (Tie 793-5178)
More information about the Comp.unix.aix
mailing list