Memory / swap problem?

[Nicky_5]

Hi,

I have an HP-UX (11.11) machine.
This is running tuxedo8.0, oracle9i, weblogic 6.1.

I keep getting the error:
PID8864 received a SIGSEGV for stack growth failure.
Possible causes: insufficient memory or swap space, or stack size exceeded maxssize.

Also can someone tell me what is the meaning of :
Swap Mbytes:In Use = 630 Reserved = 1418 Available = 0.

Please advice what is wrong.

[A. Clay Stephenson]

This could mean several things: maxdsiz, maxdsiz_64bit,maxssiz,maxssiz_64bit kernel limits need to be increased; out of virtual memory -- you need more swap space.

The second line does not appear to be the output of a standard command like swapinfo BUT it appears that you are out of swap space. You need to add more swap or reduce the memory footprint of your system by reducing things like database shared memory structures.

I suspect that you are seeing a rather high pageout rate indicating that you need more physical memory but lack of physical memory will cause poor performance not program crashes. Lack of virtual memory (of which swap is a component) will cause program crashes.

[Devesh Pant_1]

What does your swapinfo -tam output looks like?

[Nicky_5]

hi,

Please see the swapinfo and kernel values:

swapinfo -tam
Mb Mb Mb PCT START/ Mb
TYPE AVAIL USED FREE USED LIMIT RESERVE PRI NAME
dev 2048 674 1374 33% 0 - 1 /dev/vg00/lvol2
reserve - 1374 -1374
memory 1506 652 854 43%
total 3554 2700 854 76% -
0 -
=========================
kmtune -lq maxdsiz
Parameter: maxdsiz
Current: 1073741824
Planned: 1073741824
Default: 0x10000000
Minimum: -
Module: -
Version: -
Dynamic: No

kmtune -lq maxdsiz_64bit
Parameter: maxdsiz_64bit
Current: 2147483648
Planned: 2147483648
Default: 0x0000000040000000
Minimum: -
Module: -
Version: -
Dynamic: No


kmtune -lq maxssiz
Parameter: maxssiz
Current: 134217728
Planned: 134217728
Default: 0x00800000
Minimum: -
Module: -
Version: -
Dynamic: No


kmtune -lq maxssiz_64bit
Parameter: maxssiz_64bit
Current: 1073741824
Planned: 1073741824
Default: 0x00800000
Minimum: - Module: -
Version: -
Dynamic: No

[Steven E. Protter]

swap space is needed even if its never used. When processes start, they reserve it.

If you are actually paging processes in and out of swap, you need to add memory to the system.

Paging really slows down the system.

I'd like to see some vmstat info, perhaps swapinfo -tam to see how hard swap is being hit and how much is in use.

If you are not paging and there simply is not enough swap, then increasing it is all you need to do. I think that unlikely.

What kind of server, hardware wise? How much memory?

SEP

[Nicky_5]

Hi,

I have pasted the swap info output in my previous post, please see other info below:

Model : 9000/800/A500-7X
No. of cpu : 2
cpu type: A500-7X 2.0 PA8700
Kernel 64 bits
Memory info (from sam):
Physical Memory: 2049.8 MB
Real Memory:
Active: 726385.3 KB
Total: 1601000.9 KB
Virtual Memory:
Active: 1543163.1 KB
Total: 3265962.5 KB
Free Memory Pages: 15340 at 4 KB/page
Swap Space:
Avail: 2048 MB
Used: 2048 MB

:>vmstat 1 15
procs memory page faults cpu
r b w avm free re at pi po fr de sr in sy cs us sy id
2 0 0 380344 16987 9 2 5 6 0 0 88 429 2459 470 2 0 98
2 0 0 380344 16925 9 1 3 0 0 0 0 413 1983 432 2 0 98
2 0 0 380344 16933 8 0 2 0 0 0 0 412 2136 461 0 0 100
2 0 0 380344 16933 6 0 2 0 0 0 0 411 2039 437 0 0 100
2 0 0 380344 16933 4 0 2 0 0 0 0 411 1939 418 1 0 99
3 0 0 380708 16933 3 0 1 0 0 0 0 409 2100 450 0 1 99
3 0 0 380708 16933 2 0 1 0 0 0 0 408 1976 431 0 0 100
3 0 0 380708 16933 1 0 1 0 0 0 0 408 1860 413 1 0 99
3 0 0 380708 16933 0 0 1 0 0 0 0 408 2031 446 0 0 100
3 0 0 380708 16933 4 0 1 0 0 0 0 411 2018 439 0 1 99
3 0 0 380708 16933 3 0 1 0 0 0 0 410 1967 433 1 0 99
3 0 0 380708 16933 2 0 1 0 0 0 0 444 2201 470 0 0 100
3 0 0 380708 16933 1 0 1 0 0 0 0 436 2196 445 1 2 97
3 0 0 380708 16933 0 0 1 0 0 0 0 432 2089 425 1 0 99
3 0 0 380708 16933 0 0 0 0 0 0 0 428 2255 460 0 0 100

[Don Morris_1]

Just to cover the obvious -- but did you run a debugger on the resulting corefile from PID8864's termination and see what it was doing? (How much stack was in use, etc.). If this was a 64-bit app, you could exhaust the swap remaining listed above given your maxssiz_64bit... if it was a 32-bit app, then either you're going to have to raise maxssiz if you think it is behaving properly (Fortran/Java use a lot of stack) or get the app fixed if not (lots of recursion, big local arrays within functions in C).

[Nicky_5]

hi,
i am new to all this, i dont know where is the core file or how to run the debugger,
how do i find out how much stack was in use?

please advice.

[Don Morris_1]

Core file is placed in the current working directory of the application that failed.

Debuggers are typically invoked as: debugger binary core-file... (example: gdb /usr/local/bin/dumper /tmp/core))... once you're in there, you can get a back trace of the stack, get information on the top frame, etc. At the least, the backtrace on the stack should give the app developer an idea of where it failed and why.

Given that you aren't familiar with a debugger (and I'm guessing aren't a programmer), it may be a more worthwhile use of your time to simply locate the core file, do "file core" to find out what application dumped core -- and contact your support (internal/external/whatnot) for that application to resolve if this stack growth is intentional or a bug.