ulimit command vs maxdsiz kernel parameter

[MikeL_4]

I have following set in kernel for maxdsiz:
maxdsiz 1073741824
maxdsiz_64bit 1073741824
The ulimit command shows:
=>ulimit -Hd
1048576
and it can't be changed:
=>ulimit -d 1572864
sh: ulimit: The specified value exceeds the user's allowable limit.
=>

If maxdsiz parameters are set and if they govern the ulimit -Hd command, why can't I increase it? or could you please correct my thought process.....

Thanks

[Mel Burslan · Accepted solution]

Mike,

I have had the same exact problem withthe same exact limit you experienced and here is how Clay explained my dilemma:

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=860078

hope it helps you understand your situation.

[Bill Hassell]

It looks like ulimit was set before the user logged in. ulimit -d some-value is identical to ulimit -Hd some-value and the limit cannot be raised. If ulimit is changed with -Sd, then the limit can go up and down. Once -H is used (or -d without -S) then the -d limit can only be made smaller.

Look in /etc/profile, any scripts that it calls and also look at .profile for ulimit values.

[Don Morris_1]

I don't understand your question.

Yes, the maxdsiz{_64bit} parameters set the system-wide hard limits that ulimit tends to report. (Note that a sufficiently priviledged user that your shell is a child of could always have lowered the hard limit for your process tree, resulting in a lower value than the system-wide limit... superuser can raise the hard limit back up to the system limit, man rlimit for all these gory details...). Without raising those tunables (static in 11.11 v1 and earlier, dynamic in 11.11 v2 and later [yes, I left 11.20 out -- static there, and I hope no one still runs that!] you can not increase the hard limit.

Also note: the tunable values are in bytes, ulimit reports in kb. In the data you provided, ulimit reports 1048576. 1073741824/1024 = 1048576, so this is consistent.

As a result, there's no surprise that your ulimit change request failed -- you tried to set the limit above the system-imposed maximum defined by the maxdsiz tunable. You'll need to raise both tunables to have a larger 32-bit data limit. This is because most shells are 32-bit (and use the maxdsiz limit), but the system process which spawns them is 64-bit and uses maxdsiz_64bit. 32-bit children with 64-bit parents get the more restrictive limit between the system limit and the parent's limit, so the 64-bit tunable when lower actually ends up overriding the 32-bit tunable for just about any process people might care about. You'll also likely have to use chatr for 32-bit programs if you truly need this data space, since the default address layout gives less than 1Gb architecturally anyway.

Is this any more clear -- or am I too haphazard with my thoughts this morning?

[MikeL_4]

Actually it's starting to get a little clearer than mud although it get's confusing figuring out all of these different values. It looks like the DBA's are trying to set the limit at about 1 1/2Gb and the maxdsiz is only 1Gb so it's failing...

Is there anywhere that explains the different options for the ulimit command ?

[Don Morris_1]

That would depend on which shell you're using.

From the documentation search on docs.hp.com, it looks like the POSIX shell has the most options, documentation on that is at:

http://docs.hp.com/en/B2355-90690/sh-posix.1.html

(should be a manpage on your system as well).

The ulimit section is:

ulimit [-HSacdfnst] [limit]

*

Set or display a resource limit. The limit for a specified resource is set when limit is specified. The value of limit can be a number in the unit specified with each resource, or the keyword unlimited.
*

The -H and -S flags specify whether the hard limit or the soft limit is set for the given resource. A hard limit cannot be increased once it is set. A soft limit can be increased up to the hard limit. If neither -H nor -S is specified, the limit applies to both. The current resource limit is printed when limit is omitted. In this case, the soft limit is printed unless -H is specified. When more than one resource is specified, the limit name and unit are printed before the value.
*

If no option is given, -f is assumed.
-a

List all of the current resource limits.
-c

The number of 512-byte blocks in the size of core dumps.
-d

The number of kilobytes in the size of the data area.
-f

The number of 512-byte blocks in files written by child processes (files of any size can be read).
-n

The number of file descriptors.
-s

The number of kilobytes in the size of the stack area.
-t

The number of seconds to be used by each process.

It might be a good idea to scan the man pages for getrlimit/setrlimit as well -- that's the infrastructure the text/data/stack limits are built ontop of. (The kernel tunables for text/data/stack limits set the hard limits when the system boots up and things work from there).

[Don Morris_1]

And yup -- that's exactly what's happening in your original message. The hard limit (and the maxdsiz tunable) is 1Gb, the value desired is about 1.5Gb. If the DBAs want a higher data limit, you (or they, whichever is appropriate) need to do the following:

1) Raise maxdsiz and maxdsiz_64bit to at least 1610612736.

If you aren't on 11i v2 or later, make sure the kernel gets rebuilt, reboot, etc. [stock tunable change stuff].

2) ulimit should now report your higher limit. [Caveat: If you set maxdsiz to 2Gb, ulimit may now report unlimited. This is because of how RLIMIT_INFINITY was defined back when the rlimit standard was done. The tunable (and limit) can actually be larger than INFINITY's value, and HP-UX doesn't allow for truly unbounded data. Just mentioning this up front in case you have nitpicky DBAs.]

3) The process the DBAs care about will then need to use the appropriate address space layout to get >1Gb private space. If you're in the default layout (Share Magic) you get (1Gb - maxssiz - 4096), to get more you need to use Exec Magic (2Gb - maxssiz - 4096 - Text space). To get more than that you need to chatr for q3 and/or q4 private. Only do what you have to -- since making more space private means you have less space for shared libraries and such... you can get private copies of shared libraries if you have to, but that's a waste of space if the application doesn't truly need 3.75Gb of private data space. If the DBA truly only needs 1.5Gb of data, then Exec magic should be sufficient with the usual stack and a reasonable Text segment.

[MikeL_4]

Thanks for all your help.....