Hi,

I would like to know how to find out Memory Utilization on Linux.

as I Know from below command

[test@test ~]$ free -m
total used free shared buffers cached
Mem: 7984 7925 58 0 13 6175
-/+ buffers/cache: 1736 6247
Swap: 8189 6988 1201

from above screenshot entire memory will be buffered. as and when it is required by Application or Database it will from Buffer only.


So how to find out % Utilization of Memory?

according to this:
total mem = 7984 and used mem = 7925 (6175 of which is eaten by caching - which saves you from using swap)
therefor you are (7925-6175)/7984*100 = 21.92% in use by applications in memory.
and 6175/7984*100= 77.34% is in use as cache to save you from swapping.

that said, you're swapping 6988/8189*100 = 85.3% of your swap space...

care to share your uptime? (I bet it's high)
seeing as how low your mem usage is, I would expect it was much higher at some point in the past, so your swap file ran up and just stayed there.

First you would need to define "Memory Utilization". Any belief that there is a simple, generally useful, definition implies a misunderstanding of memory use. It is complicated and hard to precisely define and harder to measure.

A good crude measure of memory use for some purposes is the first number on the -/+ buffers/cache line you quoted. When that measure is not good enough, a better measure may be very hard to find.


I read that a few times and still have no clue what it was supposed to communicate.

Based on the output you posted, most of your RAM is used by cache, which is typical and usually indicates proper operation.

A large amount and a large fraction of swap is in use. There are many possible causes for that unusual condition. Some are symptoms of problems that should be understood and corrected. Others might be symptoms of an unusual workload for which it would be much safer to have significantly more swap space allocated. Other causes might be perfectly normal and not indicate any change should be made.

That is one plausible theory for the posted memory stats. That theory implies a widely varying workload for which the existing 8GB of swap space is not safe. It implies the system came very close to aborting processes due to lack of swap space (or maybe even did abort processes due to lack of swap space).

1 members found this post helpful.

If you want to use less swap add/adjusting the /etc/sysctl.conf value vm.swappiness. This is a tunable kernel parameter that controls how much the kernel favors swap over RAM.

by default its not in the file so check it down:

|/proc/sys/vm# cat swappiness
60

The higher % the vm.swappiness value, the more the system will swap. I normally run my oracle servers around 10% since I don't want them to swap at all...

Enterprise server you could always add more memory Good luck.

That is a terrible idea. Using less swap should not be a goal. The large use of swap shown by the OP might or might not be a symptom of a problem. If it is a symptom, disguising the problem makes the problem worse not better. If it isn't a problem, suppressing correct swapping makes performance worse.

I'm sure you have the common misunderstanding of the relationship of swapping to other similar activities. So by setting swappiness low you have increased the rate at which pages must be read in from disk. If you have plenty of memory, you haven't changed the behavior much and you have only slowed your system a little. But if that parameter change made any significant difference, it made you system significantly slower.

Maybe I'm missing something here. I agree data going to swap is determined to be sent there due to low usage but at the same point its normally a form of lower speed disk or in a non-enterprise server the same disk as the OS where as anything in the buffer/cache row is memory on the board (i.e. nanoseconds vs. milliseconds). Why would the access to the swap be faster if I needed to read it if I have real memory to spare? Am I overlooking a design here where pdflush might be scanning all non-swap memory for free page cleanup overhead and if so why would Oracle best practices be to set this value extremely low if the cost of pulling a page from cache/free mem is cheaper than pulling it from swap?

For the simple explanation, consider two common states for pages in ram:
1) Dirty, anonymous.
2) Clean, non anonymous.
A dirty anonymous page is typically a page of your program's heap or stack or global data. It can be other things, but those examples should help understand it.
A clean non anonymous page is often a page of executable code or read only data that was read from the main executable file or from a .so file and was never changed, so the copy in ram is known identical to the copy in a known place within an open file on disk. Again, it could be many other things, but those examples help understanding.

Memory pressure pushes pages out of a process's resident set to the cache and out of the cache, leaving ram entirely. During that flow, Linux should have some bias in favor of pushing out clean non anonymous pages vs. pushing out dirty anonymous pages.

A clean page costs nothing to push out, because it was already identical to a page on disk. When needed again, it costs just as much to read back. So the total throughput cost of pushing a clean page out and later bringing it back is half as much as for a dirty page.
An anonymous page needs a position in swap space when pushed out. A non anonymous page already has a permanent position in a file. So there is some extra resource cost to pushing out an anonymous page vs. non anonymous.

But the main decision mechanism of which pages to push out is based on approximate LRU (least recently used) because it correlates well with how soon a page will be needed back in ram.

Lowering swappiness increases the bias against pushing out anonymous pages in favor of pushing out non anonymous pages. So a recently used non anonymous page will be pushed out before a not recently used anonymous page. Typically, that non anonymous page will be needed again soon taking up time to read it back in and displacing a different non anonymous page that also needs to be read back soon.

If your media writes far slower than it reads then lowering swappiness is a good idea because that would decrease the number of writes at a typical cost of more than one read for every write saved.

If your swap space is somewhere slower than where you have ordinary files, then lowering swappiness might make sense for similar reasons.

Default swappiness provides the right bias against pushing out anonymous pages based on the assumption that a write and later reread of swap space is not far different in cost from two reads of ordinary files. Usually that is true. In that case, don't mess with swappiness.

2 members found this post helpful.