increase ulimt

[David Hausman_1]

I am trying to increase the maximum value of a ulimit for a user. Currently it is set to 1gb and I cannot increase it. I have some folks tell me I can NOT increase it - and others telling me I should be able to somewhere. The OS is HPUX 11i. thanks

[Nicolas Dumeige]

Hello,

Use ulimit -h (hardware) to see for youself.

Cheers

Nicolas

[Sundar_7]

I believe -h stands for hardlimit and not for hardware

[A. Clay Stephenson]

First, it matters which ulimit you are talking about. Do a ulimit -a and identify the one you are referring to: filesize, stack, etc. The other thing to identify is the shell you are running. In general, you can increase up to the hard ulimit value. The hard ulimits are typically set with kernel defines so you may need to build a new kernel. A little more data will help us zero in on the issue.

[David Hausman_1]

I am trying to change the option with a -d....data

[David Hausman_1]

also, the id I am trying to change is has the ksh shell

[A. Clay Stephenson]

Okay, in that case the Korn shell's ulimit only refers to the maximum file size. There is really no reason at all to run the ksh under HP-UX; most people who do, do so in the mistaken belief that /usr/bin/sh (or /sbin/sh in the case of root) are Bourne shells. They are not; instead they are POSIX are are actually a superset of the Korn shell. You have finer control over ulimit. In your case, to increase the data, you need to increase maxdsiz in the kernel, Also you should perhaps increase maxdsiz_64bit as well -- if this is 64-bit HP-UX 11.x. Eventhough the shell is a 32-bit process and you would expect maxdsiz to limit it, actually the SMALLER of maxdsiz and maxdsiz_64bit determnines the hard data ulimit. You are then allowed to increase the soft ulimit to this value.

[A. Clay Stephenson]

By the way, I should add that if this is a 32-bit process then 1GB may be the "practical" limit; memory allocations above 1GB span quadrants in 32-bit HP-UX land and as such are not allowed unless special steps are taken. For example, you can "chatr" a file to allow data segments to span quadrants. Man chatr for details.

[David Hausman_1]

currently the parameters are like this:
maxdsiz 4288256409 4288256409 Static N/A
maxdsiz_64bit 1073741824 1073741824 Static N/A


and memory is :
Memory Information:
physical page size = 4096 bytes, logical page size = 4096 bytes
Physical: 25034752 Kbytes, lockable: 23361864 Kbytes, available: 22235624 Kb
ytes


with this in mind, would it be feasable to double them?

[A. Clay Stephenson]

Note that in your case maxdsiz_64bit is 1GB and is smaller than its 32-bit counterpart. This explains why your ulimit is 1GB. The smaller of the two wins with respect to ulimit. You really should reduce maxdsiz to something more reasonable for 32-bit processes (e.g. 1GB) and increase maxdsi_64bit to perhaps 2GB. There is no point in increasing either of these above your total virtual address space and indeed swapping will lead to such poor performance that you should really reduce the limit still further. The whole idea behind these limits is to prevent a single process from grabbing inordinate amounts of resources.

[Ted Buis]

You didn't specify whether your were running 32-bit HP-UX 11i or 64-bit HP-UX 11i. Given that the 32-bit version didn't change the quadrants for memory in HP-UX, you will likely still have limits with it. Also, if you have a 32-bit application, it will be subject to 32-bit limits even on a 64-bit version of the OS. Memory windows might help if you have maxed out the kernel parameters. See http://www.docs.hp.com/hpux/onlinedocs/os/memwn1_4.pdf

[Bill Hassell]

maxdsiz set to 4Gb is meaningless. This limit is for 32bit applications which cannot address more than 960 megs without compile/linker options or chatr changes. You need to recompile your application as a 64bit program before these severe limits disappear. As mentioned, maxdsiz_64 MUST be bigger than maxdsiz. A 64bit program can address terabytes of RAM (if you had that much). Read this note top understand the difficulties with 32bit programs: http://www.uwsg.iu.edu/usail/external/tuning/mem_mgmt Note that this is an old white paper but for 32bit programs, the limitations still apply.

Note that ulimit can't be set higher that maxdsiz, and with ksh, you have no options to set anything except the number of blocks for files on disk. However, on 11i, patch PHCO_27019 seems to have granted ksh all the POSIX shell options for ulimit (although the patch readme doesn't state this).