ulimit problem with data and stack sizes.

[Mel Burslan]

I have an rp3440 system with 8GB of RAM installed in it. I am having a problem with ulimit -d command.

I would like to set the data to unlimited but it does not let me do this. I tried using the builtin ulimit command and specifying it from the full path:

# id
uid=0(root) gid=3(sys) groups=0(root),1(other),2(bin),4(adm),5(daemon),6(mail),7(lp),20(users),77(opcgrp),200(sapsys),202(oper),1001(sysadm)
# ulimit -d unlimited
sh: ulimit: The specified value exceeds the user's allowable limit.
# /usr/bin/ulimit -d unlimited
/usr/bin/ulimit[7]: ulimit: The specified value exceeds the user's allowable limit.
# /usr/bin/ulimit -aH
time(seconds) unlimited
file(blocks) unlimited
data(kbytes) 1048576
stack(kbytes) 131072
memory(kbytes) unlimited
coredump(blocks) unlimited
nofiles(descriptors) 2048

the number 1048576, corresponding to data is 1024*1024, i.e., it is the 1GB point. I know that I have 8 GB of memory on this system but still it does not let me increment this value even by a mere "1" as follows

# /usr/bin/ulimit -d 1048577
/usr/bin/ulimit[7]: ulimit: The specified value exceeds the user's allowable limit.
# ulimit -d 1048577
sh: ulimit: The specified value exceeds the user's allowable limit.
# kmtune | grep -e maxdsiz_64bit -e maxssiz_64bit
maxdsiz_64bit 17179869184 - 17179869184
maxssiz_64bit 0x40000000 - 0X40000000


I am lost here. Could someone please enlighten me ? Is there any reason why I can not set this to unlimited ? Or why can't I increase it to my available memory size, or some level close to it as I understand, there needs to be some memory reserved for kernel and such ? Also, I need to ask same question for the stack size as well ? Are there any limitations for these values regarding various kernel parameters ?

[A. Clay Stephenson · Accepted solution]

Ulimit is determined by the maxdsiz, maxssiz (32-bit) values because the shell is 32-bit. You need to increase those to what ever values you deem reasonable for 32-bit process. The _64bit values also can affect ulimit if the _64bit vales are less than their 32-bit counterparts. The smaller value then "wins".

64-bit processes are limited by the _64bit tunables.

Remember these values limit per process memory use. They consume no limit themselves but prevent any one process from grabbing all the avilable resourses. As a general rule, the stack maxssiz, maxssiz can be fairly small (64MB for 32-bit, 128MB for 64-bit) because almost anything that needs stacks larger than that are almost certainly poorly written code (the exception might be some FORTRAN code). Similarly, maxtsiz doesn't need to be that big. How many programs do you know that have 1GB of executable code? The big one is maxdsiz (and _64bit). This is the area that can grow when dynamic memory is allocated and here the sky is the limit --- within reason. For example, on development machines, you might have a rogue program consuming all the memory and no one else can do anything. With a reasonable maxdsiz_64bit, this program might grow until it allocated 4GB and then die and everyone else is still able to work. That's the function of these values -- to limit the hogs.

[A. Clay Stephenson]

By the way (and this is not meant as a putdown), your question illustrates why every admin needs to have at least a little C/C++ background. You are then able to make informed decisions when a developer or a vendor approaches you and says that he needs a 2GB stack. You then pull out your baseball bat and either beat the stack size down or the developer -- whichever you prefer.

[Shawn D. Givler]

I am having a similar problem with our HP Itanium2 with 16Gb. The kernal settings for the 32bit and _64bit maxdsiz and maxssiz have been increased to their maximum (4 & 16Gb); however, ulimit reports that maxdsiz is only 4Gb because I am checking from a 32bit shell. If I run 64bit software from that shell are they too limited to the 32bit limits as well? Is there no way to run 64bit software from a shell under the 64bit limits?

[A. Clay Stephenson]

The shell being a 32-bit process can only report its *siz values which are 32-bit values; however, a 64-bit process fork()'ed and exec()'ed (ie launched, started, spawned) by this shell is not limited by these 32-bit values.

[Shawn D. Givler]

My 64bit engineering analysis software still seems to be running into the 4Gb datasiz limit. Models that require less than 4Gb run seemlessly. Models requiring more than 4Gb halt with a message that the software's request to allocate the additional memory beyond 4Gb have failed.

[Mel Burslan]

closing this old thread