dona@milton.u.washington.edu (Donald Allen) (03/09/91)
I am trying to run an application process which requires an allocation of about 150M of memory, but am unable to do so. The largest amount of memory I have been able to get a single process to successfully acquire (using calloc or malloc, with either one or multiple calls) is about 33M; any larger request has NULL returned. However, I can launch several applications simultaneously each of which acquire 33M; so, it doesn't appear to be a limit on my account. The system is an RS6000/530 with 48M memory installed, running AIX 3.1. There is 200M of paging space declared, and before running the application, about 180M of paging space is free. Thanks in advance for any suggestions. -- Don Allen
woan@nowhere (Ronald S Woan) (03/09/91)
In article <18016@milton.u.washington.edu> dona@pooky.ee.washington.edu (Don Allen) writes: >I am trying to run an application process which requires an allocation >of about 150M of memory, but am unable to do so. The largest amount >of memory I have been able to get a single process to successfully >acquire (using calloc or malloc, with either one or multiple calls) >is about 33M; any larger request has NULL returned. Have you checked out the MAX sizes in the User Charcteristics menu of SMIT to see if you how much you are allowed to allocate? At one time, I remember hearing that it defaulted to 32MB or something like that... -- +-----All Views Expressed Are My Own And Are Not Necessarily Shared By------+ +------------------------------My Employer----------------------------------+ + Ronald S. Woan woan@peyote.cactus.org or woan%austin@iinus1.ibm.com + + other email addresses Prodigy: XTCR74A Compuserve: 73530,2537 +
jfh@greenber.austin.ibm.com (John F Haugh II) (03/09/91)
In article <18016@milton.u.washington.edu> dona@pooky.ee.washington.edu (Don Allen) writes: >I am trying to run an application process which requires an allocation >of about 150M of memory, but am unable to do so. The largest amount >of memory I have been able to get a single process to successfully >acquire (using calloc or malloc, with either one or multiple calls) >is about 33M; any larger request has NULL returned. However, I can >launch several applications simultaneously each of which acquire >33M; so, it doesn't appear to be a limit on my account. You are running up against one of two problems. The most likely one is that the data space ulimit for your account is probably 32MB or so (possibly 64MB ...). This can prevent you from making requests smaller than 128MB. Raising your data limit high enough will allow malloc() requests up to 128MB. As for the 128MB limit, it is caused by a combination of two things. First, the S/6000 has a 256MB segment size limit. Each segment is limited to 256MB, so you can't have a data segment larger than that. What aggrevates that is that the malloc() on the S/6000 comes from BSD and uses "power of 2" allocation, thus a 30MB request becomes a 32MB request, and a 34MB request becomes a 64MB request. You can figure out what happens to that 150MB request - except that your stack, data, and bss are already sharing the segment, so the malloc() call has to fail because of the 256MB segment limit. DISCLAIMER: I speak for myself only. -- John F. Haugh II | I've Been Moved | MaBellNet: (512) 838-4340 SneakerNet: 809/1D064 | AGAIN ! | VNET: LCCB386 at AUSVMQ BangNet: ..!cs.utexas.edu!ibmchs!auschs!snowball.austin.ibm.com!jfh (e-i-e-i-o)
ng@cfd.di.nrc.ca (Kai Ng) (03/11/91)
In article <3628@d75.UUCP>, woan@nowhere (Ronald S Woan) writes: |> Have you checked out the MAX sizes in the User Charcteristics menu of |> SMIT to see if you how much you are allowed to allocate? 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. |> +------------------------------My Employer----------------------------------+ |> + Ronald S. Woan woan@peyote.cactus.org or woan%austin@iinus1.ibm.com + |> + other email addresses Prodigy: XTCR74A Compuserve: 73530,2537 + -- ----------------------------------------------------------------------------- Kai S. Ng Informatics, National Research Council Canada INTERNET ng@cfd.di.nrc.ca M-60 Montreal Road, Ottawa, Canada K1A 0R6 BITNET kain@nrcvm01.bitnet VOICE (613) 993-0240 FAX (613) 954-2561
scott@prism.gatech.EDU (Scott Holt) (03/11/91)
In article <1991Mar10.180433.24685@nrcnet0.nrc.ca> ng@cfd.di.nrc.ca writes: > >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. Well, I don't know if setting them in the limits file does any good (I have not tried), but adjusting memory limits with the ulimit command does have an effect (ulimit -d). I have not tried many of the other limits, but the only one I know is not enforced is CPU time. - Scott -- This is my signature. There are many like it, but this one is mine. Scott Holt Internet: scott@prism.gatech.edu Georgia Tech UUCP: ..!gatech!prism!scott Office of Information Technology, Technical Services
zdenko@katzo.rice.edu (zdenko tomasic) (03/11/91)
In article <23999@hydra.gatech.EDU> scott@prism.gatech.EDU (Scott Holt) writes: > >Well, I don't know if setting them in the limits file does any good (I have >not tried), but adjusting memory limits with the ulimit command does >have an effect (ulimit -d). I have not tried many of the other limits, but >the only one I know is not enforced is CPU time. ^^^^^^^^^^^^^^^^^^^^^^^^^ I don't know about system calls, but I had definite experience that if my job took more than the allowed [ck]shell maximum (1 hour default), it got killed. I think the kill may not have been immediate (up to a couple of minutes), but it never got more than 20 min over the limit. > >- Scott >-- >This is my signature. There are many like it, but this one is mine. >Scott Holt Internet: scott@prism.gatech.edu >Georgia Tech UUCP: ..!gatech!prism!scott >Office of Information Technology, Technical Services -- ___________________________________________________________________ Zdenko Tomasic, Rice U., Chem. Dept., P.O. Box 1892, Houston, Tx 77251 INTERNET: zdenko@katzo.rice.edu ___________________________________________________________________
bengsig@dk.oracle.com (Bjorn Engsig) (03/11/91)
Article <18016@milton.u.washington.edu> by dona@pooky.ee.washington.edu (Don Allen) says: |I am trying to run an application process which requires an allocation |of about 150M of memory, but am unable to do so. Did you have a look at ulimit -s, ulimit -d or ulimit -m (from ksh)? They control the maximum stack, data or total memory. -- Bjorn Engsig, ORACLE Corporation, E-mail: bengsig@oracle.com, bengsig@oracle.nl
dona@pooky.engr.washington.edu (03/12/91)
In article <18016@milton.u.washington.edu> dona@pooky.ee.washington.edu (Don Allen) writes: >I am trying to run an application process which requires an allocation >of about 150M of memory, but am unable to do so. The largest amount >of memory I have been able to get a single process to successfully >acquire (using calloc or malloc, with either one or multiple calls) >is about 33M; any larger request has NULL returned. The problem was that there was a soft limit on the maximum amount of data memory that a process could use; this limit is defined in /etc/security/limits. By running the shell command "unlimit" in the shell before running the application, the soft limit is removed, and the application can allocate the memory successfully. Thanks to all who helped. -- Don Allen
bengsig@dk.oracle.com (Bjorn Engsig) (03/12/91)
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 started on Tue Mar 12 12:23:16 1991 $ ulimit -a time(seconds) 99999 file(blocks) 99999 data(kbytes) 50000 stack(kbytes) 50000 memory(kbytes) 50000 coredump(blocks) 99999 $ cc -o zz -lc -lc -lc -lc -lc 0706-317 ERROR: Unresolved or undefined symbols detected: Symbols in error (followed by references) are dumped to the load map. .main $ ulimit -d 4096 $ cc -o zz -lc -lc -lc -lc -lc xlc: 1501-227 unable to reset ulimit 0706-103 ERROR: BUMP: Allocation of 1746580 bytes failed. There is not enough memory available now. Please try again later or use local problem reporting procedures. $ ^D script done on Tue Mar 12 12:24:22 1991 -- Bjorn Engsig, ORACLE Corporation, E-mail: bengsig@oracle.com, bengsig@oracle.nl
julie@levell.austin.ibm.com (Julie A. Levell) (03/15/91)
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] <pts0> /> ulimit -a time(seconds) 3600 file(blocks) 2097151 data(kbytes) 131072 stack(kbytes) 32768 memory(kbytes) 32768 coredump(blocks) 2048 [root@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@aixwiz.austin.ibm.com IBM VMNET: JULIEL at AUSVMQ DeskNet: 4C-29/994 SpeakNet: 823-5178 (Tie 793-5178)
geoff@edm.uucp (Geoff Coleman) (03/19/91)
In article <5924@awdprime.UUCP> julie@levell.austin.ibm.com (Julie A. Levell) writes: >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. > Yes but if you look at the man page for limits in "Files Reference" manual. It's line for each of the tuneables in limits except fsize ends with "Not currently implemented" (That's not an exact quote necessarily). So are you saying they are now implemented and the documentation is out of date. Geoff Coleman Unexsys Systems
cfajs@ux1.cts.eiu.edu (Tony Schaeffer) (03/19/91)
In tring to use SMIT to set the one limit (file size) that AIX 3.1 (3000) seems to enforce, I find that a value of 1 (one) causes a value of about 8000 as seen by ulimit. For my students, 4 meg is a bit large! I can use ulimit -H -f 100 to bring the size down, but I suspect that the Soft limit is checked at run time. It has to be set on its own. Is this fixed in 3003?
jfh@greenber.austin.ibm.com (John F Haugh II) (03/20/91)
In article <1991Mar18.164527.7871@edm.uucp> geoff@edm.uucp (Geoff Coleman) writes: >In article <5924@awdprime.UUCP> julie@levell.austin.ibm.com (Julie A. Levell) writes: >>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. >> > > Yes but if you look at the man page for limits in "Files Reference" >manual. It's line for each of the tuneables in limits except fsize ends >with "Not currently implemented" (That's not an exact quote necessarily). > >So are you saying they are now implemented and the documentation is out of >date. The exact quote is "Not used.", and yes it is wrong. There are some fields which aren't used, or enforced, but most of them are. Perhaps Robin Wilson could post the definitive list of fields that are initialized in /etc/security/limits as well as the list of resource limits that are actually supported by the system. The ones which I can think of right off the top of my head that are mostly ignored are "rss" and "cpu". I know that "stack" and "data" are enforced because setting illegal values does prevent programs from executing. I know that "core" is enforced (but perhaps not initialized from the /etc/security/limits file) because you can set it to a very small value and inhibit core dumps. This question is definitely one for the FAQ posting for this group. -- John F. Haugh II | I've Been Moved | MaBellNet: (512) 838-4340 SneakerNet: 809/1D064 | AGAIN ! | VNET: LCCB386 at AUSVMQ BangNet: ..!cs.utexas.edu!ibmchs!auschs!snowball.austin.ibm.com!jfh (e-i-e-i-o)
julie@levell.austin.ibm.com (Julie A. Levell) (03/27/91)
In article <1991Mar18.164527.7871@edm.uucp> geoff@edm.uucp (Geoff Coleman) writes: >In article <5924@awdprime.UUCP> julie@levell.austin.ibm.com (Julie A. Levell) writes: > Yes but if you look at the man page for limits in "Files Reference" >manual. It's line for each of the tuneables in limits except fsize ends >with "Not currently implemented" (That's not an exact quote necessarily). > >So are you saying they are now implemented and the documentation is out of >date. The documentation is misleading at best. The core, fsize, data and stack are enforced. The cpu and rss are not. This will be fixed in the documentation. >Geoff Coleman >Unexsys Systems -- *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= 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)
julie@levell.austin.ibm.com (Julie A. Levell) (03/27/91)
In article <1991Mar19.023147.4051@ux1.cts.eiu.edu> cfajs@ux1.cts.eiu.edu (Tony Schaeffer) writes: >In tring to use SMIT to set the one limit (file size) that AIX 3.1 (3000) >seems to enforce, I find that a value of 1 (one) causes a value of >about 8000 as seen by ulimit. For my students, 4 meg is a bit large! > A very good point. I forward this to development. >I can use ulimit -H -f 100 to bring the size down, but I suspect >that the Soft limit is checked at run time. It has to be set on >its own. > >Is this fixed in 3003? This isn't fixed in 3003. The problem is there is no way for an administration to set their user's hard limits. You can set up default soft limits, but if a user knows the ulimit command, they are free to increase their soft limits as high as their hard limits. I'll post again if I hear any different story, but for now I'll take it to the Design Board. Oh Boy! -- *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= 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)