Hello, davious-ga,
Thanks for the opportunity to answer this interesting question.
(I have reproduced your answer for "cpu time," just for the record,
and added a few additional comments to it. The remainder of the
material is new, of course.)
CPU TIME - Limits the number of CPU seconds a process can use (not
clock seconds). CPU time is the amount of time the CPU actual spends
executing processor instructions and is often much less than the total
program "runs time". A program that did math for 10 seconds would use
a lot of CPU time, where as a program that simply paused for 10
seconds before display a message would use next to none.
When a process exceeds the soft CPU time limit it will be sent a XCPU
signal (and terminated if the signal isn't caught). When it exceeds
the hard limit it will be sent a kill signal.
VIRTUAL MEMORY SIZE - the most useful of the memory-related
limitations, because it includes all types of memory, including the
stack, the heap, and memory-mapped files. Attempts to allocate memory
in excess of this limit will fail with an out-of-memory error.
Specified in kilobytes, in the bash shell, as found in Linux and many
other systems.
DATA SEGMENT SIZE - Limits the amount of memory that a process can
allocate on the heap, as with malloc, calloc, C++ "new," and most
object creation in higher-level languages. Specified in kilobytes, in
the bash shell, as found in Linux and many other systems.
STACK SIZE - Limits the amount of memory a process can allocate on the
stack, as in the case of local variables in C, C++ and many other
languages. Limiting the stack size stops runaway recursive function
calls; however, it is possible to legitimately allocate large arrays
of data on the stack without unreasonable recursion. Specified in
kilobytes, in the bash shell, as found in Linux and many other
systems.
FILE SIZE - Limits the maximum size of any one file a process can
create. Specified in 512-byte blocks, in the bash shell, as found in
Linux and many other systems.
MAX USER PROCESSES - limits the number of processes the current user
is permitted to have in the process table at one time. Attempts to
start additional processes will fail.
OPEN FILES - limits the number of file descriptors belonging to a
single process. "File descriptors" includes not only files but also
sockets for Internet communication. Attempts to open additional file
descriptors will fail.
CORE FILE SIZE - Limits the size of a "core" file left behind when a
process encounters a segmentation fault or other unexpected fatal
error. Core files are images of the entire memory space used by the
process at the time of the crash, and can be used to examine the state
of the process at that time with a debugger, such as gdb. In most
cases core files are of limited utility if the process was not
compiled with debugging flags enabled. Disabling core files with a
core file size limit of zero is reasonable when the processes expected
are not C/C++ applications compiled with -g or similar or no such
debugging capability is desired. Specified in 512-byte blocks.
LOCKED MEMORY - this parameter limits the maximum amount of memory
that can be "locked down" to a specific address in physical memory by
a given process. In practice, only the root user can lock memory in
this fashion. Specified in kilobytes, in the bash shell, as found in
Linux and many other systems.
MAX RESIDENT SET SIZE - this parameter limits the amount of memory
that can be "swapped in" to physical RAM on behalf of any one process.
While patches have been offered, this limit is not actually enforced
in mainstream Linux kernels; it briefly appeared in the 2.6 series but
has been removed for now due to problems. Specified in kilobytes, in
the bash shell, as found in Unix and many other systems.
MAX TOTAL SOCKET BUFFER SIZE - this parameter limits the total amount
of memory that may be taken up by buffers holding network data on
behalf of a given process. Originated as a response to
denial-of-service attacks which worked by initiating large numbers of
connections and flooding them with input; the operating system would
buffer this data patiently while waiting for the receiving process to
cope with it. Implemented in FreeBSD; not implemented in Linux, which
does not address this issue via a configurable limit. Specified in
bytes.
PIPE SIZE - when two Unix processes communicate via a pipe or FIFO
(first in first out) buffer, as in the simple case of paging through a
directory listing with the command "ls | more", the output of the
first command is buffered before transmission to the second. The size
of this buffer, in bytes, is the pipe size. This is typically not an
adjustable parameter, except at kernel compile time.
* * *
Thanks again, I enjoyed answering this question.
Sources of information:
(re: Linux and RLIMIT_RSIZE:) LWN: Patch: mm swapping improvements
http://lwn.net/Articles/68843/
(re: SBSIZE and FreeBSD:) 923Mbits/s across the ocean
http://www.cctec.com/maillists/nanog/current/msg00217.html
The GNU bash manpage
The FreeBSD sh manpage
(Painful) personal experience |
