memory issue

[ran_li]

Hello all,

I could not sum up all the memory (used+free) to match the total physical memory, please shed light on it. Thanks!

Host has 4G physical memory
# echo phys_mem_pages/D | adb /stand/vmunix /dev/kmem
phys_mem_pages: 1048064
# getconf PAGE_SIZE
4096
1048064 * 4096 => 4292870144

# dmesg | grep -i physical
physical page size = 4096 bytes, logical page size = 4096 bytes
Physical: 4192256 Kbytes, lockable: 3116772 Kbytes, available: 3591104 Kbytes

Free memory
# echo freemem/D|adb /stand/vmunix /dev/kmem
freemem: 82476
4096 * 82476 -> 337821696

Used memory
# UNIX95= ps -e -o vsz=Kbytes -o ruser -o pid,args=Command-Line | sort -rnk1

I sum up all used memory is 1127735296

used mem + free mem = 1465556992

Where does the rest of memory go?

total mem - used mem - free mem = 2827313152

[Sundar_7]

The memory used for buffer caching and the kernel will not show up with the ps output..

What is your max_dbc_pct and min_dbc_pct set to ?

Glance gives you a better memory utilization picture.

[ran_li]

Other than glance (I don't have it), is there a way to obtain this information? Is it normal to take up to 2.8G for that? (I don't have database running on this host, just JVMs)

dbc_max_pct 50
dbc_min_pct 5

[NMory]

For all your memory questions you can check the following links:



http://www1.itrc.hp.com/service/cki/search.do?docType=EngineerNotes&searchString=UPERFKBAN00001098+++&searchCrit=allwords&search.x=28&mode=id&category=c0&search.y=7&admit=-682735245+1153948060735+28353475

http://www1.itrc.hp.com/service/cki/search.do?searchString=MEMORYKBAN00000975&docType=EngineerNotes&searchCrit=allwords&search.x=26&admit=-682735245+1153948017060+28353475&category=c0&mode=id&search.y=11

ftp://hprc.external.hp.com/memory.htm

Regards,

LN

[ran_li]

Sorry I could not access any of them.

[Sundar_7]

With Dynamic buffer cache set to so high, no wonder you are missing huge chunk of memory.

Search in the web or contact the HP support and get the meminfo binary. This is an unsupported tool that allows you to drill down further on the memory usage in the system.

[A. Clay Stephenson]

Adding up memory in a sensible fashion is extremely difficult. First of all, UNIX is virtual-memory based so that the amount of physical memory in one sense doesn't matter although it can certainly have enormous performance impact. The memory reported by ps or top is only related to process space so kernel data structures such as buffer cache are not accounted for. Even Glance has difficulty in doing this because the sum of the memory used by all processes can greatly exceed even total virtual memory. How is this possible? Consider the process space used by vi? Suppose that there are 100 instances of vi. Each one has its private data space so those count as 100 separate chunks of memory. There is no problem adding those up but consider the use of the text (instructions) of those 100 vi instances. There is but one text space that is shared by all the instances. Does that count as 1 or 100? It goes even further, functions within shared libraries might be used in hundreds of processes so how do you count that space usage? It's the shared space that makes your question far from a simple one and indeed it is all but impossible to answer without narrowly defining your terms.

[NMory]

These are the document IDs, that you can use to search them in the technical knowledgebase in ITRC:


MEMORYKBAN00000975
UPERFKBAN00001098


LN

[Mel Burslan]

Every memory problem a system administrator have or had has a different solution under the specific circumstances of the server and applications running on it.

But as a rule of thumb, you should not have dbc_max_pct at 50% on a 4GB physical memory system. Pull that parameter down to 7-8 level and you will see a relief immediately. Then you debug if there is any problem left on your system.

[ran_li]

Thank you all for the comments, I will investigate more.

Regards!

[Jaime Bolanos Rojas.]

ran li,

Also to make your life a lot easier, there is a trial version for 60 days of glance plus, which is very helpfull on those cases.

Regards,

Jaime.