Sungju's Slow Life

Personal journal


How to check memory usage in Linux – part 1.1 – System level memory usage check

free

It is showing the overall memory usage in the system and how much is available to use.

We are usually focusing on used and free column to see how much memory was consumed and how much is available to use. There are some monitoring tools focus on those two columns only and alarming if the free becomes less than what was configured to monitor. It isn’t purely correct, however, as there are memory in cache that is reclaimable.

Actual available amount of memory is free plus reclaimable part of buff/cache which is calculated as the last column available in the free output. Depends on the type of cache, it may take sometime to reclaim it, so, when there is a high memory pressure, it is a good idea to make sure the cache ratio is adjusted to make it less occupy the memory.

top

top shows various information. It is quite useful when you want to see the total memory usage as well as some active processes’ memory usage. It can be considered as free + ps aux.

For the per-process memory usage, there are three columns related to that – VIRT, RES and SHR.

VIRT is virtual memory allocation size which is the amount process has requested via various memory allocation functions. This amount is not same as physically allocated amount and mostly not reach into that level.

RES is showing the amount allocated in physical memory. When we are checking memory pressure, we are checking this part.

SHR is a subset of RES which is showing the shared memory amount by various sharing functions such as posix shm* functions, mmap SHARED, and shared libraries, etc.

vmstat

This can show the free style output continuously. As it is also shows system load and other information, it is convenient to check both system load and memory usage in parallel.

/proc/meminfo

It shows the memory usage in system-wide. You can find physical memory allocation as well as virtual memory allocation/limit. It also shows you the reclaimable memory amount, shared memory, huge-ages, etc.

You can find quite detailed explanation about /proc/meminfo at Red Hat’s article – Interpreting /proc/meminfo and free output for Red Hat Enterprise Linux.

/proc/buddyinfo

Linux kernel manages the memory in page unit. To make efficient memory management and to minimise external fragmentation, it is trying to combine any neighbour pages together when it is possible. So, the name comes. [Buddy memory allocation]. From the left column, it presents 2^n pages, so, it is 1 page, 2 pages, 4 pages, 8 pages, etc. In general when the system is not in memory pressure, you are seeing some numbers on the right side of the column.

/proc/pagetypeinfo

It is similar to /proc/buddyinfo, but shows further details. This and other above /proc files related information can be found at https://www.kernel.org/doc/Documentation/filesystems/proc.txt.

/proc/slabinfo

While buddy algorithm minimises the external fragmentation, SLAB allocation helps internal fragmentation in pages. In most situation, kernel is using slab allocations instead of direct page allocation. /proc/slabinfo shows how much memory was used for the specific slab and how much in that slab is actually used and how much is still available to use without allocating new pages.

Most concerned columns is pagesperslab, num_slabs, objsize,active_objs and num_objs.

  • pagesperslab : Per-SLAB page size to allocate
  • num_slabs : Currently allocated slab count. Total amount will be pagesperslab X num_slabs
  • objsize : SLAB consists of objects. Each object represent one allocation that can be used. Each SLAB has fixed object size and can only take that specific size.
  • num_objs : Total objects created by allocating SLABs
  • active_objs : It represents how many objects are currently in use among num_objs

slabtop

slabtop is acting like top, but for the slab info data. It shows which SLAB is main consumer and how much is allocated/used for slab.

ipcs

It shows SystemV IPC information. Regarding memory usage, Shared Memory Segments is the main concern as it is allocating big amount of memory to use among processes.

We can see who is the owner of this shared memory with what permission. We also can see how much is allocated for that segment and how many processes are attached – nattach. Please be aware that this memory allocation doesn’t represent the physical allocation. It still follows copy-on-write style memory allocation which means only allocate when there’s access on that specific page.



Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: