madsiz question

[mobidyc]

Hello,

on every server i can connect i've the same behavior:
#> ldd /usr/lib/dld.sl
/usr/lib/dld.sl: Call to mmap() failed - TEXT /usr/lib/dld.sl
/usr/lib/dld.sl: Not enough space

is there a normal behavior or must i reevaluate the maxdsiz value ?

Regards,
Cedrick Gaillard

[Bill Hassell]

Without any information about your version of HP-UX or the current settings for maxdsiz, madssiz and maxtsiz (and the _64 bit parameters too), I can only guess that maxdsiz is at the default (very small) limit of 64 megs. Change it to 900 megs and also change maxdsiz_64 to something larger than maxdsiz, perhaps 4Gb. Use kctune to see you current settings (kmtune if you're running 11.11 or earlier, sysdef if you're running 10.20 or earlier).

Look at your swap space with:

swapinfo -tam

If you have very small RAM (less than 2Gb), then you may need a lot of additional swap space. Also make sure your current ulimit -m value is unlimited which means it is the same as maxdsiz.

[James R. Ferguson]

Hi Cedrick:

No, this isn't normal behavior! You need to evaluate not only your 'maxdsiz' values (32 and 64-bit) but also your swapspace. It is possible that you do not have enough swap space available for process reservation.

Regards!

...JRF...

[mobidyc]

Hello,

the swap space for these servers is small but seems to be sufficient enough.


hpux 11.00:
# kmtune -q maxdsiz -q maxdsiz_64bit
Parameter Value
===============================================================================
maxdsiz 0X0000000040000000
maxdsiz_64bit 0X0000000040000000
# swapinfo -tam
Mb Mb Mb PCT START/ Mb
TYPE AVAIL USED FREE USED LIMIT RESERVE PRI NAME
dev 2048 0 2048 0% 0 - 1 /dev/vg00/lvol2
reserve - 2048 -2048
memory 3139 1128 2011 36%
total 5187 3176 2011 61% - 0 -
# ldd /usr/lib/dld.sl
/usr/lib/dld.sl: Call to mmap() failed - TEXT /usr/lib/dld.sl
/usr/lib/dld.sl: Not enough space
# ulimit -aH |grep memory ; ulimit -aS |grep memory
memory(kbytes) unlimited
memory(kbytes) unlimited
# /opt/Toolsets/bin/kmeminfo
tool: kmeminfo 5.19
unix: /stand/vmunix 11.00 64bit PA2.0 on "nr0u0132"
core: /dev/kmem live
link: Wed Dec 1 12:39:09 MET 2004
boot: Sat Sep 9 23:47:14 2006
time: Tue Apr 3 14:54:34 2007
nbpg: 4096 bytes


----------------------------------------------------------------------
Physical memory usage summary (in page/byte/percent):

Physical memory = 1048576 4.0g 100%
Free memory = 195341 763.1m 19%
User processes = 518439 2.0g 49% details with -user
System = 330505 1.3g 32%
Kernel = 225648 881.4m 22% kernel text and data
MALLOC = 92397 360.9m 9% memory buckets
bucket[5] = 2909 11.4m 0% size 32 bytes
bucket[6] = 139 556.0k 0% size 64 bytes
bucket[7] = 3429 13.4m 0% size 128 bytes
bucket[8] = 1092 4.3m 0% size 256 bytes
bucket[9] = 2795 10.9m 0% size 512 bytes
bucket[10] = 5000 19.5m 0% size 1024 bytes
bucket[11] = 70828 276.7m 7% size 2048 bytes
bucket[12] = 187 748.0k 0% size 4096 bytes
bucket[13] = 316 1.2m 0% size 2 pages
bucket[14] = 195 780.0k 0% size 3 pages
bucket[15] = 52 208.0k 0% size 4 pages
bucket[16] = 10 40.0k 0% size 5 pages
bucket[17] = 24 96.0k 0% size 6 pages
bucket[18] = 0 0.0b 0% size 7 pages
bucket[19] = 16 64.0k 0% size 8 pages
bucket[20] = 5391 21.1m 1% size > 8 pages
reserved = 14 56.0k 0% reserved pools
Super page pool = 56512 220.8m 5% details with -kas
Static Tables = 62280 243.3m 6% details with -static
pfdat = 23806 93.0m 2%
nbuf = 12251 47.9m 1% bufcache headers
htbl2_0 = 8192 32.0m 1%
pfn_to_virt = 3967 15.5m 0%
bufhash = 2560 10.0m 0% bufcache hash headers
Other tables = 11503 44.9m 1% details with -static
Buffer cache = 104857 409.6m 10% details with -bufcache

hpux 11.11:
# kmtune -q maxdsiz -q maxdsiz_64bit
Parameter Current Dyn Planned Module Version
===============================================================================
maxdsiz 0xfffff000 - 0XFFFFF000
maxdsiz_64bit 0x400000000 - 0X400000000
# swapinfo -tam
Mb Mb Mb PCT START/ Mb
TYPE AVAIL USED FREE USED LIMIT RESERVE PRI NAME
dev 10240 148 10092 1% 0 - 1 /dev/vg00/lvol2
dev 6144 118 6026 2% 0 - 1 /dev/vg00/swap_2
reserve - 15856 -15856
memory 20509 6647 13862 32%
total 36893 22769 14124 62% - 0 -
# ldd /usr/lib/dld.sl
/usr/lib/dld.sl: Call to mmap() failed - TEXT /usr/lib/dld.sl
/usr/lib/dld.sl: Not enough space
# ulimit -aH |grep memory ; ulimit -aS |grep memory
memory(kbytes) unlimited
memory(kbytes) unlimited
# /opt/Toolsets/bin/kmeminfo
tool: kmeminfo 5.19
unix: /stand/vmunix 11.11 64bit PA2.0 on "nr0u0150"
core: /dev/kmem live
link: Thu Jun 15 14:32:56 METDST 2006
boot: Thu Aug 3 15:41:45 2006
time: Tue Apr 3 14:55:25 2007
nbpg: 4096 bytes


----------------------------------------------------------------------
Physical memory usage summary (in page/byte/percent):

Physical memory = 6806784 26.0g 100%
Free memory = 2089391 8.0g 31%
User processes = 2698155 10.3g 40% details with -user
System = 2001275 7.6g 29%
Kernel = 1320597 5.0g 19% kernel text and data
Dynamic Arenas = 734216 2.8g 11% details with -arena
vx_inode_cache = 229102 894.9m 3%
vx_global_pool = 173773 678.8m 3%
ALLOCB_MBLK_LM = 97261 379.9m 1%
ALLOCB_MBLK_SM = 64046 250.2m 1%
vx_buffer_cache = 37216 145.4m 1%
Other arenas = 132818 518.8m 2% details with -arena
Super page pool = 164140 641.2m 2% details with -kas
Static Tables = 354673 1.4g 5% details with -static
pfdat = 155730 608.3m 2%
nbuf = 69392 271.1m 1% bufcache headers
htbl2_0 = 65536 256.0m 1%
pfn_to_virt = 25955 101.4m 0%
bufhash = 20480 80.0m 0% bufcache hash headers
Other tables = 17579 68.7m 0% details with -static
Buffer cache = 680678 2.6g 10% details with -bufcache

hpux 11.23:
#> kctune maxdsiz maxdsiz_64bit

Tunable Value Expression Changes
maxdsiz 2063835136 2063835136 Immed
maxdsiz_64bit 0x40000000 0x40000000 Immed
#> swapinfo -tam
Mb Mb Mb PCT START/ Mb
TYPE AVAIL USED FREE USED LIMIT RESERVE PRI NAME
dev 8192 0 8192 0% 0 - 1 /dev/vg00/lvol2
reserve - 938 -938
memory 4096 1037 3059 25%
total 12288 1975 10313 16% - 0 -
#> ldd /usr/lib/dld.sl
/usr/lib/dld.sl: Call to mmap() failed - TEXT /usr/lib/dld.sl
/usr/lib/dld.sl: Not enough space
#> ulimit -aH |grep memory ; ulimit -aS |grep memory
max memory size (kbytes, -m) unlimited
virtual memory (kbytes, -v) unlimited
max memory size (kbytes, -m) unlimited
virtual memory (kbytes, -v) unlimited
#> /opt/Toolsets/bin/kmeminfo
tool: kmeminfo 5.19
unix: /stand/vmunix 11.23 64bit PA2.0 on "nr0u0131"
core: /dev/kmem live
link: Thu Dec 28 18:07:48 EST 2006
boot: Thu Mar 22 11:35:49 2007
time: Tue Apr 3 14:55:49 2007
nbpg: 4096 bytes


----------------------------------------------------------------------
Physical memory usage summary (in page/byte/percent):

Physical memory = 1048576 4.0g 100%
Free memory = 546542 2.1g 52%
User processes = 201930 788.8m 19% details with -user
System = 296296 1.1g 28%
Kernel = 243868 952.6m 23% kernel text and data
Dynamic Arenas = 114331 446.6m 11% details with -arena
vx_global_kmcac = 32891 128.5m 3%
vx_buffer_kmcac = 18304 71.5m 2%
mdep arena = 14441 56.4m 1%
spinlock = 13630 53.2m 1%
M_LVM = 4843 18.9m 0%
Other arenas = 30222 118.1m 3% details with -arena
Super page pool = 76294 298.0m 7% details with -kas
Static Tables = 52271 204.2m 5% details with -static
pfdat = 24575 96.0m 2%
htbl2_0 = 8192 32.0m 1%
nbuf = 4704 18.4m 0% bufcache headers
pfn_to_virt = 4095 16.0m 0%
text = 3529 13.8m 0% vmunix text section
Other tables = 7174 28.0m 1% details with -static
Buffer cache = 52428 204.8m 5% details with -bufcache

i've found this problem since users indicates to me that they are bad when they try to connect to database through perl scripts with the DBI module.

unable to say if the problem with dld.sl was here before.

Regards,
Cedrick Gaillard

[Hein van den Heuvel]

Does that command even make sense?
It's just an ugly way of saying 'bad target'.

Hein.

[Rasheed Tamton · Accepted solution]

Hello,

Bill Hassell has always been my Guru since years on different forums.

Anyway, please see the link for more info.

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


Regards,
Rasheed Tamton.

[Hein van den Heuvel]

Well, Bill is my hero also, but he's got it wrong this time, and send Cedrick of to do a rockfetch.
You just can not do ldd on dld.sl.
Why would you want to?

It's that old question, which Bill also likes to ask but did not ask this time:

'What problem are you really trying to solve?'

Grins,
Hein.

[Bill Hassell]

Thanks Hein...I looked at the error message rather than the command itself.

[Dennis Handly]

Typically this error means you are out of shared memory. And you would look at ipcs -ma.

>Bill: I looked at the error message rather than the command itself.

But you didn't notice "TEXT". ;-)

>Hein: You just can not do ldd on dld.sl.
Why would you want to?

Right. If you do this on IPF you get a nicer message:
ldd: "/usr/lib/hpux32/dld.so" is not a shared executable.

It looks like Rasheed found a previous thread.

Note you can use chatr(1).

[mobidyc]

Hello,

Rasheed: thanks for your link, i'm now sure it's not a problem but a normal behaviour ;)

for your question : why would i want to do an ldd on dld.sl

the answer is simple:
Users have an error message "can't load ....perl/5.6.0/PA-RISC2.0/auto/DBD/Oracle/Oracle.sl' for module DBD::Oracle: Not enough space at....."

when i've done an ldd on the ....perl/5.6.0/PA-RISC2.0/auto/DBD/Oracle/Oracle.sl library, i've obtained the following error message:
/usr/lib/dld.sl: Can't open shared library: /hpx/work/ee/8.1.7.4/hpx32/src_0424/lib//libwtc8.sl
/usr/lib/dld.sl: No such file or directory

i know that this error message is concerning libwtc8.sl (SHLIB_PATH was not positionned) but i've done an ldd on dld.sl because i used to do that.

for the problem behind, there's no filesystem full, no swap or memory load so, i'm going to increase the maxdsiz value.

Regards,
Cedrick Gaillard