suspected memory problem

[TMcB]

Since upgrading from HPUX10.20 to HPUX11.00 last Christmas, we have noticed a problem with our free memory.
There is 2GB of memory in the server.
After a reboot on Friday, the memory was sitting at 40% used.
Today, it is now sitting at 98% used - and the system is running incredibly slow because of this.

I wanted to contact you because I suspect we have a problem with memory not being released.

Below is an example of our "top memory users" - the top sessions listed are not running anything - the users are sitting logged in not doing anything, but they are still claiming the most memory.
Is there anything we can check?

[Ravi_8]

Hi,

These are the reason everybody recommend for cold install rather than upgrade.

use glnce plus which give a hint about the memory usage by each process. Let's know the result

[TMcB]

Hi

soory - it was a cold install of 11.00 we carried out (figure of speach(.

Glance results :
B3692A GlancePlus C.03.71.00 10:16:51 shse001 9000/898 Current Avg High
------------------------------------------------------------------------------------------------------------------------------------
CPU Util S SA ARU U | 35% 35% 35%
Disk Util F F |100% 100% 100%
Mem Util S SU UB B | 99% 99% 99%
Swap Util U UR R | 46% 46% 46%
------------------------------------------------------------------------------------------------------------------------------------
MEMORY REPORT Users= 92
Event Current Cumulative Current Rate Cum Rate High Rate
--------------------------------------------------------------------------------
Page Faults 217 217 144.6 144.6 144.6
Page In 21 21 14.0 14.0 14.0
Page Out 0 0 0.0 0.0 0.0
KB Paged In 268kb 268kb 178.6 178.6 178.6
KB Paged Out 0kb 0kb 0.0 0.0 0.0
Reactivations 0 0 0.0 0.0 0.0
Deactivations 0 0 0.0 0.0 0.0
KB Deactivated 0kb 0kb 0.0 0.0 0.0
VM Reads 17 17 11.3 11.3 11.3
VM Writes 0 0 11.3 0.0 0.0

Total VM : 262.4mb Sys Mem : 94.4mb User Mem: 899.7mb Phys Mem: 2.00gb
Active VM: 131.7mb Buf Cache: 1024mb Free Mem: 29.9mb Page 1 of 1

[Bill Hassell]

From the memory report in Glance, you can see that 50% of your memory is being used by the buffer cache. This is a common problem and the kernel parameter dbc_max_pct must be changed to about 20 to 30 (400-600 megs). That will return a lot of memory. NOTE: The buffer cache grows to the maximum value when there is no other processes needing the memory. This however assumes that you are up to date on patches (at lease a 2004 Quality Pack and HWE set).

Since Page Outs = 0, it would appear that memory is not the source of slow response in your system. Lowering the dbc_max value will show unused memory but I don't think you'll see any difference in performance. To see all the top users of memory, use this command:

UNIX95= ps -o vsz,ruser,pid,args | sort -rn | head -20

That will show the top 20 memory hogs. Increase -20 if you need to see more. The users may not be dpoing anything, but an idle program waiting on something from a user will not release memory. As with all performance issues, the programs that are running slow must be identified first. Is it login delays? Or compile times are very slow? Or execution of the same program with the same data is now 10x slower?

[TMcB]

Hi Bill
Thanks for replying.

dbc_max_pct is currently at 50.
I'll make arrangements to decrease this on our test server first of all.

We currently have QualPack and HWE from Sept03 installed.

The system itself does not appear slower to me, but quite a few users are complaining that while accessing an informix application, they are experiencing delays.

[Bill Hassell]

Sep2003 is OK. The first step in performance analysis is to narrow down the symptom. Informix, like Oracle can be (mis)configured and/or be suffering from bad SQL or lack of needed indexes. I'll bet that it probably starts up the same as it always has, and seems to slow down with certain queries. Time for the DBA to get involved. If possible, allocate more RAM to the Informix engine and look at your busiest disks (sar -d 2 10). Make sure Informix is using the raw device files (logical volumes that always start with the letter: r.

[TMcB]

Hi

We reduced db_max_pct from 50 to 20 - memory has been at 40% since we rebooted.
Thought everything was going well until users received the following error -


Pid 7438 received a SIGSEGV for stack growth failure.
Possible causes: insufficient memory or swap space,
or stack size exceeded maxssiz.
Memory fault

Suspect it may have somthing to do with :
maxdsiz 67108864
maxssiz 8388608
maxtsiz 67108864


Has anyone any idea about this?

Thanks

[A. Clay Stephenson · Accepted solution]

maxdsiz 67108864
maxssiz 8388608
maxtsiz 67108864

These are almost certainly too small. Reasonable values for maxdsiz might be about 512MB, 32-64MB for maxssiz, and 256MB for maxtsiz. You may also be facing limits with shmmax. Increasing these values consume no additional resources but they do allow a single process to consume resources up to these limits.

[TMcB]

Thanks for getting back.

shmmax is currently 400MB -
I'll have a go at increasing these 4 parameters.

Bye