Outflow of memory

[Nitsulenko Sergey]

I stop Oracle. Processes are not present. Memory is exempted only in part. What can be the reason?

[John Palmer]

Hi,

How did you shut Oracle down? Normal shutdown routines will remove shared memory, killing the Oracle processes won't.

Some more information would be useful.

Regards,
John

[Stefan Farrelly]

What does;

ipcs -m | grep oracle

show ? it lists shared memory used by oracle instances/databases. Normally on a db shutdown these are freed up.

[Nitsulenko Sergey]

ipcs -m
IPC status from /dev/kmem as of Fri Feb 7 14:05:55 2003
T ID KEY MODE OWNER GROUP
Shared Memory:
m 0 0x411c061a --rw-rw-rw- root root
m 1 0x4e0c0002 --rw-rw-rw- root root
m 2 0x41200379 --rw-rw-rw- root root
m 6659 0x0c6629c9 --rw-r----- root root
m 4 0x06347849 --rw-rw-rw- root root
m 1029 0xffffffff --rw-r--rw- root root
m 29191 0x00280267 --rw-r--r-- root root

[Dietmar Konermann]

Obviously there is no Oracle shmem segment left.

I think you should be more precise, what you mean by "Memory is exempted only in part". What metric are you watching?

When you look at "free memory", as reportet by Glance, top or vmstat, then you should note thaz this is free physical memory.

When you shutdown your database then you can expect that your swapspace recovers to the original amount (swapinfo -t, watch the "total" summary).

But you cannot expect that freemem returns. It's the kernel's decision how to utilize physical memory. Remember that parts of physmem are used for caching, so they are only freed when it's really needed.

Best regards...
Dietmar.

[Steven E. Protter]

Try some longer term data collection with the attached data collection script. Post any questions you have about it. Everything runs background and you can control how long the data collection process runs.

I have found looking at snapshots much less useful than a long, careful data collection.

If you have a memory leak, these tools will help you spot the trend.

SEP

[Nitsulenko Sergey]

Thanks, I shall try, But it is interesting why standard commands show different resultst:

top
....
Memory: 101900K (65352K) real, 86196K (57076K) virtual, 1765960K free Page# 1/7
.......

adb -k /stand/vmunix /dev/kmem (With the subsequent processing)
Memory = 1689 megs

dmesg
..........
Memory Information:
physical page size = 4096 bytes, logical page size = 4096 bytes
Physical: 3145728 Kbytes, lockable: 2666372 Kbytes, available: 2737124 Kbytes
........

swapinfo -t
Kb Kb Kb PCT START/ Kb
TYPE AVAIL USED FREE USED LIMIT RESERVE PRI NAME
dev 1048576 0 1048576 0% 0 - 1 /dev/vg00/lvol2
dev 2621440 0 2621440 0% 0 - 1 /dev/vg03/lvol9
dev 2621440 0 2621440 0% 0 - 1 /dev/vg04/lvol10
reserve - 4093128 -4093128
memory 2385144 369148 2015996 15%
total 8676600 4462276 4214324 51% - 0 -

[T G Manikandan]

top does not give the proper information on the available memory.

The dmesg output is right.
you can also use

echo phys_mem_pages/D | adb /stand/vmunix /dev/kmem

to get the same results.

Thanks

[Frank Slootweg]

You are not comparing apples to apples and are misinterpreting what you are reading:

top(1) does not say what you *think* it says. Read the manual page to interpret what it is saying. And use top(1) for its primary purpose, which is to report *CPU* usage, not memory usage.

adb(1): I do not know which "Memory" you are taking about, so I can not comment.

dmesg(1M) reports only the *static*, not dynamic, information *at bootup*.

swapinfo(1M): The "memory" line does *not* report memory usage, it just reports how much memory is included in the *calculation* of *swap* space, hence the name swapinfo, not memoryinfo or some such.

Bottom line: Tell us what you want to know and why and we can give suggestions. If you have the Glance tool, then please use that.

[Nitsulenko Sergey]

>Bottom line: Tell us what you want to know and why and we can give suggestions. If you have the Glance tool, then please use that.

Look, please, the very first message.

[Frank Slootweg]

Sorry, but your first message is not specific enough.

As is clearly evident from this thread, there is a *lot* of confusion about memory usage and therefor we have to know *exactly* what you want to know and why.

[Dietmar Konermann]

Still open questions:

What you mean by "Memory is exempted only in part". What metric are you watching?

[Frank Slootweg]

As I think there is also a language problem here:

What Dietmar means is that you are using some utility to look at some values(s). What we want/need/must know is:

Which utility? Which commands/options/parameters/screens/etc. are you using? Which fields (i.e. their 'names') are you looking at? What are their values? Which values do you expect? Why? Etc..

If the issue is that 'memory utilization' ("Mem Util" in Glance) is 'high' (90% or more) and that memory is not 'freed' ("Free Mem" in Glance) when processes terminate, then the answer is: That is *normal*. HP-UX uses main (RAM) memory as a cache and a good cache is always full. HP-UX keeps memory *nearly* full (around 95%) in order to allow small processes to start quickly.

In other words, a memory utilization of 90-95% is *not* bad, it is *good*, i.e. you did not buy too much memory.

[Nitsulenko Sergey]

Thanks Frank, now all began on the places. Last question - me disturbs only Curent and Cumulative values Page Faults displayed in GlancePlus: periodically rise up to 1296 and 8301 (accordingly).

[Frank Slootweg]

Don't worry about page faults, they are *not* page *in/out*s.

Watch Mem Util. If it is (around) 95% or less, then memory pressure is OK and you do not have to look at the other memory/paging/swapping numbers.

*If* you look at paging/swapping, then look at Page Requests, KB Paged In and Out and Deactivations and Reactivations.

[Nitsulenko Sergey]

Thank You very mach!