Home/ Questions/Q 3855514
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-19T17:47:17+00:00

The only program relevant I know of is pmap , but this only prints

  • 0

The only program relevant I know of is pmap, but this only prints the memory of one process.

I would like to see how the physical memory is occupied and by which processes/library, including the kernel, of the entire physical RAM (as opposed to that from the process’ POV with pmap).

Ideally also with a graphical interface.

Do you know if there’s any such tool?

I know about the ambiguity introduced by libraries. If it’s the case, it could display a 1-pixel wide line and an arrow to the real location of that library.

What do I need this for? To view the RAM fragmentation.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Memory Fragmentation

    When a Linux system has been running for a while memory fragmentation can increase which depends heavily on the nature of the applications that are running on it. The more processes allocate and free memory, the quicker memory becomes fragmented. And the kernel may not always be able to defragment enough memory for a requested size on time. If that happens, applications may not be able to allocate larger contiguous chunks of memory even though there is enough free memory available. Starting with the 2.6 kernel, i.e. RHEL4 and SLES9, memory management has improved tremendously and memory fragmentation has become less of an issue.

    To see memory fragmentation you can use the magic SysRq key. Simply execute the following command:

    # echo m > /proc/sysrq-trigger

    This command will dump current memory information to /var/log/messages. Here is an example of a RHEL3 32-bit system:

    Jul 23 20:19:30 localhost kernel: 0*4kB 0*8kB 0*16kB 1*32kB 0*64kB 1*128kB 1*256kB 1*512kB 1*1024kB 0*2048kB 0*4096kB = 1952kB)
Jul 23 20:19:30 localhost kernel: 1395*4kB 355*8kB 209*16kB 15*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 12244kB)
Jul 23 20:19:31 localhost kernel: 1479*4kB 673*8kB 205*16kB 73*32kB 21*64kB 847*128kB 473*256kB 92*512kB 164*1024kB 64*2048kB 28*4096kB = 708564kB)

    The first line shows DMA memory fragmentation. The second line shows Low Memory fragmentation and the third line shows High Memory fragmentation. The output shows memory fragmentation in the Low Memory area. But there are many large memory chunks available in the High Memory area, e.g. 28 4MB.

    If memory information was not dumped to /var/log/messages, then SysRq was not enabled. You can enable SysRq by setting sysrq to 1:

    # echo 1 > /proc/sys/kernel/sysrq

    Starting with the 2.6 kernel, i.e. RHEL4 and SLES9, you don’t need SysRq to dump memory information. You can simply check /proc/buddyinfo for memory fragmentation.

    Here is the output of a 64-bit server running the 2.6 kernel:

    # cat /proc/buddyinfo

Node 0, zone DMA 5 4 3 4 3 2 1 0 1 1 2
Node 0, zone Normal 1046 527 128 36 17 5 26 40 13 16 94
# echo m > /proc/sysrq-trigger
# grep Normal /var/log/messages | tail -1
Jul 23 21:42:26 localhost kernel: Normal: 1046*4kB 529*8kB 129*16kB 36*32kB 17*64kB 5*128kB 26*256kB 40*512kB 13*1024kB 16*2048kB 94*4096kB = 471600kB
#

    In this example I used SysRq again to show what each number in /proc/buddyinfo is referring to.

    Source: http://www.puschitz.com/pblog/

    • 0