is my malloc() failing due to swap reaching it's max limit ?

[scoolj]

subsequent malloc () calls in my programs, are failing, and I suspect it is due to no swap reserves ?

Could you pls advise ? swap and kernel parameters/usage is below.

Thanks in advance.

ciao,
Srini

*** SWAPINFO ***

$ swapinfo -tam
Mb Mb Mb PCT START/ Mb
TYPE AVAIL USED FREE USED LIMIT RESERVE PRI NAME
dev 4096 0 4096 0% 0 - 1 /dev/vg00/lvol2
reserve - 4096 -4096
memory 130811 41002 89809 31%
total 134907 45098 89809 33% - 0 -


*** KCUSAGE ***

$ kcusage
Tunable Usage / Setting
=============================================
dbc_max_pct 2 / 3
maxdsiz 83734528 / 2063835136
maxdsiz_64bit 951214080 / 4294967296
maxfiles_lim 693 / 6144
maxssiz 1114112 / 314572800
maxssiz_64bit 90112 / 1073741824
maxtsiz 3051520 / 128000000
maxtsiz_64bit 2523136 / 1073741824
maxuprc 237 / 10235
max_thread_proc 681 / 3001
maxvgs 1 / 100
msgmni 0 / 10240
msgseg 0 / 32767
msgtql 0 / 32000
nfile 6152 / 125228
nflocks 48 / 8212
ninode 2177 / 98192
nkthread 3682 / 14387
nproc 446 / 10240
npty 4 / 120
nstrpty 7 / 120
nstrtel 0 / 60
nswapdev 1 / 10
nswapfs 0 / 10
semmni 31 / 10240
semmns 85 / 20480
shmmax 23100672 / 24576000000
shmmni 14 / 1024
shmseg 5 / 1024


*** KERNEL TUNABLE PARAMS ***

Tunable Value Expression Changes
NSTREVENT 50 Default
NSTRPUSH 16 Default
NSTRSCHED 0 Default
STRCTLSZ 1024 Default
STRMSGSZ 65535 65535
acctresume 4 Default
acctsuspend 2 Default
aio_listio_max 256 Default Immed
aio_max_ops 2048 Default Immed
aio_monitor_run_sec 30 Default Immed
aio_physmem_pct 10 Default
aio_prio_delta_max 20 Default Immed
aio_proc_thread_pct 70 Default Immed
aio_proc_threads 1024 Default Immed
aio_req_per_thread 1 Default Immed
allocate_fs_swapmap 0 Default
alwaysdump 1 1 Immed
chanq_hash_locks 256 Default
core_addshmem_read 0 Default Immed
core_addshmem_write 0 Default Immed
create_fastlinks 1 1
dbc_max_pct 3 3 Immed
dbc_min_pct 3 3 Immed
default_disk_ir 0 Default
disksort_seconds 0 Default
dma32_pool_size 268435456 Default
dmp_rootdev_is_vol 0 Default
dmp_swapdev_is_vol 0 Default
dnlc_hash_locks 512 Default
dontdump 0 Default Immed
dst 1 Default
dump_compress_on 1 Default Immed
enable_idds 0 Default
eqmemsize 15 Default
executable_stack 0 Default Immed
fr_statemax 800000 Default
fr_tcpidletimeout 86400 Default
fs_async 0 Default
fs_symlinks 20 Default Immed
ftable_hash_locks 64 Default
gvid_no_claim_dev 0 Default
hp_hfs_mtra_enabled 1 Default
intr_strobe_ics_pct 100 Default Auto
io_ports_hash_locks 64 Default
ioforw_timeout 0 Default Auto
ksi_alloc_max 81920 81920 Immed
ksi_send_max 32 Default
max_acct_file_size 2560000 Default Immed
max_async_ports 50 Default
max_mem_window 0 Default
max_thread_proc 3001 3001 Immed
maxdsiz 2063835136 2063835136 Immed
maxdsiz_64bit 4294967296 Default Immed
maxfiles 4096 4096
maxfiles_lim 6144 6144 Immed
maxrsessiz 8388608 Default
maxrsessiz_64bit 8388608 Default
maxssiz 314572800 314572800 Immed
maxssiz_64bit 1073741824 1073741824 Immed
maxtsiz 128000000 128000000 Immed
maxtsiz_64bit 1073741824 Default Immed
maxuprc 10235 10235 Immed
maxvgs 100 100
msgmap 10242 10242
msgmax 8192 Default Immed
msgmnb 65535 65535 Immed
msgmni 10240 10240
msgseg 32767 32767
msgssz 512 512
msgtql 32000 32000
ncdnode 150 Default
nclist 8292 Default
ncsize 95120 95120
nfile 125228 125228 Imm (auto disabled)
nflocks 8212 8212 Imm (auto disabled)
nfs3_adaptive_cache_validate 0 Default
ninode 8192 8192
nkthread 14387 14387 Immed
nproc 10240 10240 Immed
npty 120 120
nstrpty 120 120
nstrtel 60 Default
nswapdev 10 Default
nswapfs 10 Default
nsysmap 8400 Default
nsysmap64 8400 Default
o_sync_is_o_dsync 0 Default
pa_maxssiz_32bit 83648512 Default
pa_maxssiz_64bit 536870912 Default
pagezero_daemon_enabled 1 Default Immed
pfdat_hash_locks 128 Default
physical_io_buffers 1792 Default Auto
region_hash_locks 128 Default
remote_nfs_swap 0 Default
rng_bitvals 9876543210 Default
rng_sleeptime 2 Default
rtsched_numpri 32 Default
scroll_lines 100 Default
scsi_max_qdepth 8 Default Immed
scsi_maxphys 1048576 Default
secure_sid_scripts 1 Default Immed
semaem 32767 32767
semmni 10240 10240
semmns 20480 20480
semmnu 10236 10236
semmsl 2048 Default Immed
semume 250 250
semvmx 65535 65535
sendfile_max 0 Default
shmmax 24576000000 24576000000 Immed
shmmni 1024 1024 Immed
shmseg 1024 1024 Immed
st_ats_enabled 0 Default
st_fail_overruns 0 Default
st_large_recs 0 Default
st_san_safe 1 1 Immed
str_mblk_lock_per_cpu 4 Default
str_mem_cache_enable 1 Default
str_mem_cache_size 50 Default
str_mem_global_cache_size 16 Default
str_meta_extn_size_max 1024 Default
str_n_dup_cnt 31 Default
streampipes 0 Default
streams_sqmax 1000 Default
swapmem_on 1 Default
swchunk 16384 16384
sysv_hash_locks 128 Default
tcphashsz 2048 Default
timeslice 10 Default
timezone 420 Default
unlockable_mem 0 Default
vnode_cd_hash_locks 128 Default
vnode_hash_locks 128 Default
vol_checkpt_default 10240 Default
vol_dcm_replay_size 262144 Default
vol_default_iodelay 50 Default
vol_fmr_logsz 4 Default
vol_max_bchain 32 Default
vol_max_nconfigs 20 Default
vol_max_nlogs 20 Default
vol_max_nmpool_sz 4194304 Default Immed
vol_max_prm_dgs 1024 Default
vol_max_rdback_sz 4194304 Default Immed
vol_max_vol 8388608 Default
vol_max_wrspool_sz 4194304 Default Immed
vol_maxio 256 Default
vol_maxioctl 32768 Default
vol_maxkiocount 2048 Default
vol_maxparallelio 256 Default
vol_maxspecialio 256 Default
vol_maxstablebufsize 256 Default
vol_min_lowmem_sz 532480 Default Immed
vol_mvr_maxround 256 Default
vol_nm_hb_timeout 10 Default
vol_rootdev_is_vol 0 Default
vol_rvio_maxpool_sz 4194304 Default Immed
vol_subdisk_num 4096 Default
vol_swapdev_is_vol 0 Default
vol_vvr_transport 1 Default
vol_vvr_use_nat 0 Default
volcvm_cluster_size 16 Default
volcvm_smartsync 1 Default
voldrl_max_drtregs 2048 Default
voldrl_min_regionsz 512 Default
voliomem_chunk_size 65536 Default
voliomem_maxpool_sz 4194304 Default
voliot_errbuf_dflt 16384 Default
voliot_iobuf_default 8192 Default
voliot_iobuf_limit 131072 Default
voliot_iobuf_max 65536 Default
voliot_max_open 32 Default
volpagemod_max_memsz 6144 Default Immed
volraid_rsrtransmax 1 Default
vps_ceiling 64 64
vps_chatr_ceiling 1048576 Default
vps_pagesize 4 Default
vx_maxlink 32767 Default
vx_ninode 90000 90000 Immed
vxfs_bc_bufhwm 0 Default Immed
vxfs_ifree_timelag 0 Default Immed
vxtask_max_monitors 32 Default
$


*** ULIMIT ***
$ ulimit -a
time(seconds) unlimited
file(blocks) unlimited
data(kbytes) 4294967292
stack(kbytes) 307200
memory(kbytes) unlimited
coredump(blocks) 4194303

[Don Morris_1]

Unless "subsequent malloc() calls" are for around 41Gb of memory, I rather doubt it.

$ swapinfo -tam
Mb Mb Mb PCT START/ Mb
TYPE AVAIL USED FREE USED LIMIT RESERVE PRI NAME
dev 4096 0 4096 0% 0 - 1 /dev/vg00/lvol2
reserve - 4096 -4096
memory 130811 41002 89809 31%
total 134907 45098 89809 33% - 0 -

This shows all your (very, very small) device swap is reserved. (4Gb for a ~146Gb system (assuming the usual 11.23 which this must be due to physical_io_buffers being in the listing ratio of 7/8) Seems a little small, but I suppose it could happen). However, memory swap will satisfy malloc()'s reservations just as well.

Since you'd hit maxdsiz _or_ maxdsiz_64bit (2Gb / 4Gb respectively from the kcusage output) way before the swap limits... I'd strongly suspect that's the limit you're hitting.

And I don't know what ulimit is smoking -- but your data limit is not 4294967292 kbytes [that would be 4Tb or so... which is rather beyond your tunable limitations].

It would help if you'd give some idea of how much was being requested of malloc() at the time of the failure, and how much had previously been acquired via malloc(). That should give us a rough idea (barring malloc implementation details... you'd need to use Glance or pstat or dump a core file and get the actual size of the PS_DATA object to really know precisely the size).

[Don Morris_1]

Argh, dratted column shifting -- make that 89Gb or so available of memory swap, not 41Gb. Not that it matters here, I expect.

[scoolj]

My process was topping 700MB before a subsequent malloc() failed to allocate 14MB.

Even a small memtest program is able to allocate(in chunks) upto the total of 4GB with out any issues.

But still unsure why my process was failing due to failure of such a small allocation.

If the data(kbytes) 4GB shown by ulimit(in the Question) is wrong ? then is this what causing subsequent malloc() failures.

In my case, what should be the typical value to be set for data(kbytes) in ulimit ?
And how to set it ?

What are the other possible factors which may force malloc() to be failed inspite of sufficient memory on the machine side.

Sorry, the machine is in production at customer site & not accessible at this time.

Thanks much.

[Dennis Handly]

>My process was topping 700MB before a subsequent malloc() failed to allocate 14MB.

This is reasonable for a 32 bit application with a ridiculously large maxssiz.

>If the data 4GB shown by ulimit (in the Question) is wrong?

No, this value is for 64 bit apps.

>what should be the typical value to be set for data in ulimit? And how to set it?

It is set by the kernel parm maxdsiz and maxdsiz_64bit.

>What are the other possible factors which may force malloc() to be failed in spite of sufficient memory on the machine side.

32 bit app and a ridiculously large maxssiz.

>the machine is in production at customer site & not accessible at this time.

You use fire to fight fire, use "ulimit -s" to reduce maxssiz.

[scoolj]

The machine in concern is HP Itanium v11, and the process that was mallocing also an HP_UX IA64 release.

Thanks, I will try "ulimit -s" to reduce maxssiz.

[Don Morris_1]

Noting that Dennis has already replied to a lot of this:

"My process was topping 700Mb when it failed"

That means your process was compiled as 32-bit and with default settings. Such a process has 1Gb for Text, 1Gb for Private Data, and 2Gb for Shared data (though in discrete 1Gb chunks... there's some importance to the topmost 1Gb [the Global Shared Window]). Your value for maxssiz (which affects 32-bit processes) is 314572800, or roughly 300Mb. That comes out of the 1Gb of private data, hence your best case scenario is about 700Mb -- and you get exactly what you see.

To get more you have to either compile 64-bit or compile to a different address space layout (such as MPAS, man chatr, read the Adaptive Address Space white paper, probably man ld as well, there's a ton of resources on this stuff) which gives more space to Private data.

ulimit is wrong because it should be capped by either maxdsiz or maxdsiz_64bit. maxdsiz is never above 4Gb. maxdsiz_64bit is not 4Tb (it is closer to 4Gb). ulimit is reporting roughly the value of maxdsiz_64bit... but as kbytes instead of bytes [the tunables are in bytes] hence ulimit is off by a factor of 1024 or so from being possible.

I don't honestly think the limits in the kernel ulimit is based on are wrong -- I suspect ulimit itself is reporting incorrectly. Nothing to stress over, just worth pointing out. In general, ulimit is irrelevant to the data line anyway, because the tunable sets the true hard limit of the system -- you can only use ulimit to go lower on a per-application basis, not higher.

In summary, as Dennis correctly states -- this instance fails where it does because maxssiz is too high to give you more of your data space. Your options are to lower it globally, lower it temporarily only for a select set of processes (on v2 it is dynamic and only affects processes started after the change to it), set the hard limit for the process / shell lower than the tunable using ulimit -- or recompile the process in question to a different address space layout to give more private data. MPAS is the best you could do for 32-bit (4Gb private) but should not be used willy-nilly for all processes as all the private addresses can lead to performance degradation in the translation cache layers (see the whitepaper). 64-bit is a better option.

[scoolj]

Hi Don, the process in concern is a 64 Bit process, it was very well compiled with +DD64 on HP_UX Itanium v11, and even when I run file command, this process and all it's related eco(other utilities, binaries, .so etc., that we released along with the product) were too showing as 64 bit.

[Dennis Handly]

>the process in concern is a 64 bit process, it was compiled with +DD64 on HP-UX Itanium v11,

This doesn't make sense at all. Our theories match exactly with 32 bit.
(Also there is no such thing as "v11". There is 11i v2 and 11i v3, or just use the numbers: 11.23 11.31)

>even when I run file command

What do you see? "ia64" doesn't mean 64 bit.

[scoolj]

Sorry, if I confused you. I was refering to HP-UX 11i v11.23 Itanium version.

I remember my earlier attempts to check the native format, the file command identified all the binary files
as ELF-64 or something similar which contained 64 bit for sure.

The below is our internal utility which retrieves all the files from ported/installed product.

...
vmssan3> SUBSYSTM SSAN3V2 2.7.0.04 HPUXIA64 Sep 7 2007 17:36:07 IDS2.7.04
vmssan3> interf SSAN3V2 2.5.0.01 HPUXIA64 Sep 7 2007 17:36:08 IDS2.7.04
Revision: 1.292.2.29
vmssan3> n3erw SSAN3V2 2.3.0.00 HPUXIA64 Sep 7 2007 17:36:59 IDS2.7.04
Revision: 1.12.2.15
vmssan3> n3msg SSAN3V2 2.3.0.00 HPUXIA64 Sep 7 2007 17:36:29 IDS2.7.04
Revision: 1.11.2.4
vmssan3> n3ovr SSAN3V2 2.3.0.01 HPUXIA64 Sep 7 2007 17:36:41 IDS2.7.04
Revision: 1.50.2.17
vmssan3> n3ovr2 SSAN3V2 2.5.0.02 HPUXIA64 Sep 7 2007 17:36:52 IDS2.7.04
Revision: 1.2.2.11
vmssan3> n3rep SSAN3V2 2.3.0.02 HPUXIA64 Sep 7 2007 17:36:29 IDS2.7.04
Revision: 1.18.2.3
vmssan3> ssapr SSAN3V2 2.5.0.00 HPUXIA64 Sep 7 2007 17:36:33 IDS2.7.04
Revision: 1.44.2.12
...

Earlier...the same product in 32bit version was pretty stable on Customer's HP PRISC 32bit for years. However the same product in 64bit version built on HP-UX Itanium v11.23 pretty much allocates upto 4GB in our build environment, but failing to do so on customer's HP_UX Itanium v11.23.

[Don Morris_1]

ia64 only runs 11.20 or later, so yeah -- you have to mean v2 or v3 [r11.23 or 11.31... no one should run 11.20 if they can avoid it, and I would hope everyone is off of 11.22 to 11.23 anyway].

Back to the problem at hand -- if this is a 64-bit application, then there are only a few other possibilities.

Note first that a 64-bit IPF process shouldn't be limited in this fashion by private mmap's (they go in Octant 4 with the stack by default, heap starts in Octant 3 and grows to Octant 4, though it can't cross the octant in a single malloc()). An IPF Octant is frankly, HUGE. We're talking at least petabytes, maybe exabytes [I'm not sure how many bits we support out in user space... if the full amount, yeah... exabytes]. 700Mb is nothing to an Octant -- and you'd have one all to yourself as the Heap.

1) There's something else running that eats all the swap -- keep an eye on swapinfo while you run the application (loop it). Or Glance or whatever is your favorite tool. If the TOTAL/FREE entry (total row, free column) goes to 0, that's the problem... you just have to find what used it... because it wasn't this 700Mb based on your prior output. Glance / top and virtual process size would be a good place to start.

2) You're running this as the child of a 32-bit shell where someone used ulimit / setrlimit() to limit data to 700Mb. Such a specific limit is applied to children because that's the rlimit standard [I think this is POSIX, but it may be a different standard]. If you can recompile the app, consider printing the result for a getrlimit() call with RLIMIT_DATA, both Soft and Hard limits... that's what the app will be held to. If those aren't in line with the tunable, someone up your process tree modified the limits.

3) Your malloc() error is something else like EINVAL because you actually corrupted the heap. Dennis and I have been going from the assumption that you got ENOMEM (most common), but malloc() does have other failure modes. Check the error number so we're not barking up the wrong tree.

[Dennis Handly]

>I remember my earlier attempts to check the native format, the file command identified all the binary files as ELF-64 or something similar which contained 64 bit for sure.

Please provide the output of file(1) so we can make sure. file(1) will say:
/usr/bin/ksh: ELF-32 executable object file - IA64
/stand/vmunix: ELF-64 executable object file - IA64

32 bit would explain: My process was topping 700MB before a subsequent malloc() failed to allocate 14MB.

>Don: 3) Your malloc() error is something else like EINVAL because you actually corrupted the heap.

I've never seen this. If the heap is corrupted it usually gets a signal.

[scoolj]

Hi Dennise, I believe I have already updated above...earlier we did compile a memtest program with +DD64 flag, and executed this program in the same user session, and the shell where the actual failure point originated.

The memetest is able to allocate (devided into small chunks) upto to the total 4GB memory.

So can we now believe both /usr/bin/ksh and /stand/vmunix are 64bit ?

Will double check /usr/bin/ksh and /stand/vmunix on customer box.

[scoolj]

Dennis, I got the file command output as well, from the customer's HP-UX Itanium B.11.23, below goes...

$ file /usr/bin/ksh
/usr/bin/ksh: ELF-32 executable object file - IA64
2)
$ file /stand/vmunix
/stand/vmunix: ELF-64 executable object file - IA64

You see anything unusual in the above output ?

[Patrick Wallek]

I think they were actually wanting the 'file' output from YOUR executables. The output they showed was merely an example showing the difference between 32-bit and 64-bit.

[Dennis Handly]

>So can we now believe both /usr/bin/ksh and /stand/vmunix are 64bit?

No, one is 32 and the other 64. I chose those as examples.

>Will double check /usr/bin/ksh and /stand/vmunix on customer box.

That would be a waste since they only come in the color black. :-)

[scoolj]

Dennis, I got the output of file[file `find . -name "*" -print`] command, was run on the directory where our app was installed on HP-UX Itanium B.11.23, pls see the attachments.

[Dennis Handly]

>I got the output of file was run on the directory where our app was installed

Ok, it shows everything is 64 bit.
You do have a core file from java with SIGABRT, core.java. This wasn't the application in question?

If your application is truly 64 bit, what happens when malloc fails? Do you create a core file? Or print a message and exit?
How did you determine "topping 700MB"?

[scoolj]

Thanks Dennis.

I know, you are pointing to the below Java/core in the attached log.
./ids2704/bin/core.java: core file from 'java' - received SIGABRT

But looking at the possible amount of swap reserve(near to 80GB as mentioned previously) /w "pseudo swapping enabled" on their HP_UX Itanium B.11.23, it is hard to believe that Java is consuming a huge memory.
$ swapinfo -tam
Mb Mb Mb PCT START/ Mb
TYPE AVAIL USED FREE USED LIMIT RESERVE PRI NAME
dev 4096 0 4096 0% 0 - 1 /dev/vg00/lvol2
reserve - 4096 -4096
memory 130811 41002 89809 31%
total 134907 45098 89809 33% - 0 -


Our software(collection of server processes) is written in C and Java, and error in concern is thrown by these process written in C(error attached below, a subsequent malloc failed to allocate 14512879 bytes).
...
ids5.dbg:[402170734 ssasrsv  50/ 53] errmsg_put 'find_set(8040): no mem for 'search' (14512879 bytes)'
ids5.dbg:[402170735 ssasrsv  50/ 53] errmsg_put 'find_set(8040): no mem for 'search' (14512879 bytes)'
ids5.dbg:[402170737 ssasrsv  50/ 53] errmsg_put 'find_set(8040): no mem for 'search' (14512879 bytes)'
ids5.dbg:[402170740 ssasrsv  50/ 53] errmsg_put 'find_set(8040): no mem for 'search' (14512879 bytes)'
...

Our software exposes APIs in several forms (Java, C, C++, Cobol and so on). Customer had developed there own Java client and calling our Java APIs from it.

We have tested the same Java APIs in a peak volume and tough conditions, but not seeing any issue.

Customer has informed us that at the time of failure, the process was topping at 715MB.

So I was only wondering to see, if there is any major dependency on HP_UX Itanium B.11.23 which may be a similar to the case above...

I have recently requested to customer to debug the environment using this loop: clean up; Start the system a fresh; start vmstat 1 and keep logging it to a file; start another Java client; sleep for a sec; start another client...sleep for a sec...

Hopefully the log should reveal how the memory is eaten up...and hope that helps in finding the reason for my malloc() failures.

[Dennis Handly]

>it is hard to believe that Java is consuming a huge memory.

But is java running in 64 bit mode?

>error in concern is thrown by these process written in C

So you don't have any java in that process? Or is this C a JNI?

>Customer has informed us that at the time of failure, the process was topping at 715MB.
>start another Java client;

What was the process? And is this a 64 bit java client?

[scoolj]

Yes, Java was running in 64 bit mode.

No, the process was developed in C, not not related to JNI, but a backend/server process for engine that allocates memory and works on processing data. This is the process topping at 715 MB.

[Patrick Wallek]

>>but a backend/server process for engine that
>>allocates memory and works on processing
>>data. This is the process topping at 715 MB.

So is this process 32-bit or 64-bit?

[scoolj]

64 Bit.

See comments from Dennise above...
> Ok, it shows everything is 64 bit.

[Dennis Handly]

>See comments from Dennis above...

Don't quote me. I still think it is a 32 bit process. :-)

Unless something is using setrlimit(2) as Don mentioned.

One way to track this down is to use:
tusc -fp -a -o tusc.out command ...

You also should reduce maxssiz.

[scoolj]

Sure, I will give a try with tusc as well.

Currently on HP_UX Itanium B.11.23, users are using other supporting s/w such as Java, Oracle which might need big stacks.

So you still want us to reduce maxssiz ? currently it is 314572800(300MB), what should be the reasonable value should be set to ?