"memory map limit" in 11.31 v3

[Anar Veliyev]

Hi.

We got some peculiar soft that requires "memory map limit" be configured as one of kernel tunables. We got the following setting:
- "ia64 hp server rx7640"
- "4 Intel(R) Itanium 2 9100 series processors (1.6 GHz, 18 MB)"
- HP-UX 11.31 v3

We're not sure which kernel tunable is on "memory map limit".
Would be grateful for any clue on.

Best Regards.

[Steven E. Protter]

Shalom,

http://forums11.itrc.hp.com/service/forums/questionanswer.do?admit=109447626+1263307715469+28353475&threadId=194314

That might help.

a bit more detail including sharing what kind of software is asking this might help get you more specific answers.

SEP

[Dennis Handly]

>We're not sure which kernel tunable is on "memory map limit".

Are you talking about mmap(2)? Is this shared or private. I think the latter is controlled by maxdsiz/maxdsiz_64bit.
What size do you need?

[Anar Veliyev]

Thanks for time on the issue.

That "peculiar" soft is jBase that requires two kernel parameters being set:
- "ULIMIT: This parameter affects the maximum size of files, which a user can create and should always be set to the maximum."
- "Memory, mapped limit: used for memory-mapped files"

Note that these are chunks from the config documentation.

Below are the values for maxdsiz(_64bit) & maxssiz(_64bit) respectively:
[root@rx3600_2:BSB1 ]# kctune maxdsiz
Tunable Value Expression Changes
maxdsiz 4294963200 4294963200 Immed
[root@rx3600_2:BSB1 ]# kctune maxdsiz_64bit
Tunable Value Expression Changes
maxdsiz_64bit 4294967296 Default Immed
[root@rx3600_2:BSB1 ]# kctune maxssiz
Tunable Value Expression Changes
maxssiz 401604608 401604608 Immed
[root@rx3600_2:BSB1 ]# kctune maxssiz_64bit
Tunable Value Expression Changes
maxssiz_64bit 268435456 Default Immed
[root@rx3600_2:BSB1 ]#

jsh juser1 ~ -->ulimit -a
time(seconds) unlimited
file(blocks) unlimited
data(kbytes) 4194300
stack(kbytes) 262144
memory(kbytes) unlimited
coredump(blocks) 4194303
nofiles(descriptors) 2048
jsh juser1 ~ -->

We did increase ulimit to some value, but couldn figure out which kernel parameter does "memory map limit" match with.

Might that be the case that in 11.31 v3 no corresponding tunable?

[Dennis Handly]

>ME: Are you talking about mmap(2)? Is this shared or private?

You need to answer this question.

If shared, there may be another limit.
For shared memory there is shmmax.

>Might that be the case that in 11.31 no corresponding tunable?

I don't see one for mmap(2) shared. There is a setrlimit(2) value, RLIMIT_AS.

[Anar Veliyev]

Hi Dennis.
>Are you talking about mmap(2)? Is this shared or private?
- if you mean do we explicitly make a call to "mmap", nops.
- how could be identified whether is shared?

>If shared, there may be another limit.
For shared memory there is shmmax.
- thanks for the clue. I did `man shmmax` and came across nice info on that "group" of parameters.
-I suspect they probably have an effect on processes/threads waiting on IPC.

[Dennis Handly]

>- how could be identified whether is shared?

Looking at the source should show MAP_SHARED somewhere in the 4th parm, instead of MAP_PRIVATE.
Otherwise you could use tusc to show the system calls.

>-I suspect they probably have an effect on processes/threads waiting on IPC.

I'm not sure why you think it has to do with waiting?

[Anar Veliyev]

Thanks Dennis for the guidance on the issue.

/*
>- how could be identified whether is shared?

Looking at the source should show MAP_SHARED somewhere in the 4th parm, instead of MAP_PRIVATE.
Otherwise you could use tusc to show the system calls.
*/
- we dont have a source code for the core of the application, which drops the chance of clarifying this path further.


/*
>-I suspect they probably have an effect on processes/threads waiting on IPC.

I'm not sure why you think it has to do with waiting?
*/
- I came to that through the man page.

[Anar Veliyev]

Running `kcusage` for shared memory related tunables yields too low utilisation percentages. That probably implies the "shared memory" being out of the game for that "peculiar soft".

[Dennis Handly]

>we don't have a source code for the core of the application, which drops the chance of clarifying this path further.

You don't need the source code to use tusc. You would need it if you want to change things.

>That probably implies the "shared memory" being out of the game for that "peculiar soft".

Yes or you want it high so you don't have to change it at an inconvenient time.