interpreting free cmd output
Hello experts,
I know this is a much discussed topic, but need help to understand what do we interpret of the below:
bash-4.1$ free -m
total used free shared buffers cached
Mem: 64300 63914 385 183 694 7058
-/+ buffers/cache: 56161 8139
Swap: 31999 63 31936
The server has 64GB RAM. 20GB is allocated to Oracle as SGA. And there are about 100 Oracle server processes and its running RAC, so lets take another 2GB. In above output, cached is 7-8GB.
How can I find where is the rest being used? We have verified multiple times and there is nothing else running on the server except Oracle server.
Swap is a partition on the disk, so that 31999 is not a part of 64GB.
Transparent Huge Pages is disabled, Huge Pages is enabled and vm.nr_hugepages is set to 24576 i.e. 48GB. Is that playing a role in the above output?
Many Thanks
Responses
Pro
469 points
Hi,
From your post it is not clear if you are having any problems. Does the system perform well?
I assume you went through references like:
https://access.redhat.com/solutions/1506993
https://access.redhat.com/solutions/67610
https://access.redhat.com/solutions/1169
Enabling HugePages makes it possible for the operating system to support memory pages greater than the default (usually 4KB). Using very large page sizes can improve system performance by reducing the amount of system resources required to access page table entries. For Oracle Databases, using HugePages reduces the operating system maintenance of page states, and increases Translation Lookaside Buffer (TLB) hit ratio.
Hence, the benefits of HugePages:
a) Translation Lookaside Buffer (TLB) that caches virtual to physical address mappings can cache the addressing of more of the Oracle SGA with larger pages,
b) The amount of memory used for page tables is reduced.
Cache and buffers are considered as used memory, but they can be dropped in favor of applications whenever there is shortage of physical memory.
In your specific case:
Actual Free RAM = "free" + "buffers" + "cached"
385 + 694 + 7058 = 8137 MB (around 8GB)
Just because you have a large SGA, it does not automatically mean you will have a problem if you do not use HugePages. It is often a combination of a large SGA and lot of database connections that lead to problems. To determine how much memory you are currently using to support the page table, run the following command:
grep PageTables /proc/meminfo
Run the following command to determine the current HugePage usage:
grep Huge /proc/meminfo
You could then see if you need to tune it up:
https://oracle-base.com/articles/linux/configuring-huge-pages-for-oracle-on-linux-64
Also, take a look at this nice article:
https://fritshoogland.wordpress.com/2016/09/10/how-many-memory-is-truly-used-by-my-oracle-instance/
Also, check "slabtop -s c -o". Tools like atop can give you more clues about memory usage:
atop |grep -i memMEM | tot 62.5G | free 30.9G | cache 27.3G | buff 896.8M | slab 1.1G |
Regards,
Dusan Baljevic
Yes, that is a good explanation by Dusan. Did you try to find out process list and memory usage of each using the ps command? You may run the command "ps aux --sort=%mem" which would produce a list of processes and sorted on reverse order of their memory usage. So, you would get to see a list of those details based on memory consumption, the heavily used process would be list at the bottom. Also, look out for "RSS" column which is the actual memory consumed by each processes.
Red Hat
Guru
3719 points
In addition to the comments provided above, you could use xsos -m and/or xsos -p (ref) to get a quick surface-handle on memory utilization.
pidstat and htop are also pretty awesome.
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.