Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!romp!auschs!awdprime!levell.austin.ibm.com!julie From: julie@levell.austin.ibm.com (Julie A. Levell) Newsgroups: comp.unix.aix Subject: Re: huge memory allocation Message-ID: <5924@awdprime.UUCP> Date: 14 Mar 91 19:00:10 GMT References: <3628@d75.UUCP> <1991Mar10.180433.24685@nrcnet0.nrc.ca> <1289@dkunix9.dk.oracle.com> Sender: news@awdprime.UUCP Organization: IBM AWD, Austin Lines: 250 In article <1289@dkunix9.dk.oracle.com> bengsig@dk.oracle.com (Bjorn Engsig) writes: >Article <1991Mar10.180433.24685@nrcnet0.nrc.ca> by ng@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@oracle.com, bengsig@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@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@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@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@levell] /> ulimit -a time(seconds) 3600 file(blocks) 2097151 data(kbytes) 131072 stack(kbytes) 32768 memory(kbytes) 32768 coredump(blocks) 2048 [root@levell] /> 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@aixwiz.austin.ibm.com IBM VMNET: JULIEL at AUSVMQ DeskNet: 4C-29/994 SpeakNet: 823-5178 (Tie 793-5178)