26

The fourth column in the output of free is named shared. On most outputs I can see in internet, the shared memory is zero. But that's not the case on my computer:

$ free -h
          total        used        free      shared  buff/cache   available
Mem:       7,7G        3,8G        1,1G        611M        2,8G        3,0G
Swap:      3,8G          0B        3,8G

Here is also an excerpt of the output of ps_mem.py:

 Private  +   Shared  =  RAM used   Program
---------------------------------
 21.4 MiB +   1.0 MiB =  22.4 MiB   bash (9)
 29.2 MiB +   5.3 MiB =  34.5 MiB   Xorg
 35.9 MiB + 858.5 KiB =  36.7 MiB   tor
 42.9 MiB +   9.6 MiB =  52.5 MiB   urxvt (16)
121.0 MiB +  24.9 MiB = 145.8 MiB   okular (2)
151.8 MiB +   2.8 MiB = 154.6 MiB   soffice.bin
  3.7 GiB + 209.3 MiB =   4.0 GiB   chromium (39)
---------------------------------
                          4.6 GiB
=================================

What is the meaning of a shared memory?

Main answer in the Question 14102 says: shared: a concept that no longer exists. It's left in the output for backward compatibility. Looks insufficient to me. A "non-existent" concept does not take 600+ MB of RAM.

sourcejedi
  • 50,249
BertS
  • 611

1 Answers1

10

"Shared" in free and "Shmem" in /proc/meminfo count all the memory used by the tmpfs file system (a file system in the memory) and also the shared memory (allocated by shmget(2)). This is documented in https://www.kernel.org/doc/Documentation/filesystems/tmpfs.txt.

Here is an example from one of my servers:

$ free -k
              total        used        free      shared  buff/cache   available
Mem:      264036296     1275384   254696692     1182024     8064220   260536208
Swap:      63998972           0    63998972

$ grep Shmem /proc/meminfo
Shmem:           1182024 kB

$ df -BK | grep tmpfs
tmpfs        26403632K       51424K    26352208K   1% /run
tmpfs       132018148K         224K   132017924K   1% /dev/shm
tmpfs            5120K           4K        5116K   1% /run/lock
tmpfs       132018148K           0K   132018148K   0% /sys/fs/cgroup
tmpfs       251658240K     1129036K   250529204K   1% /run/shm
tmpfs        26403632K          24K    26403608K   1% /run/user/108
tmpfs        26403632K           0K    26403632K   0% /run/user/5800006

If you sum up the used size (3rd column) of all tmpfs filesystems listed by df, you will find the sum is equal to "shared" and "shmem".

lqhl
  • 101
  • 1
  • 6
  • Thanks for explaining, but are those tmpfs are needed, Can I delete them and if possible how do I delete them?. I have encounter this issue many times after waking up the system from hibernation(~4GB is taken by shared) – Kasun Siyambalapitiya Oct 19 '18 at 05:19
  • 2
    Hi @KasunSiyambalapitiya. Shmem also includes GEM graphics buffers, as per kernel source comments and https://lists.kernelnewbies.org/pipermail/kernelnewbies/2013-July/008628.html . Some previous versions of systemd had a bug that leaked graphics buffers (seriously) when the graphics server exited... that was "fun". https://unix.stackexchange.com/questions/431982/what-could-be-using-6gb-of-my-swap . That specific problem could only apply if your entire graphical session has been crashing, or if you have deliberately logged out of your whole session (and back in again). – sourcejedi Nov 19 '18 at 16:44
  • Your last statement is corroborated by man 5 proc (“Shmem %lu (since Linux 2.6.32) — Amount of memory consumed in tmpfs(5) filesystems.”) but not by the data you show (1312 kB are unaccounted for) and is not true in my experience (this may well depend on the kernel version). There are other sources of shared memory. sourcejedi's comment cites https://lists.kernelnewbies.org/pipermail/kernelnewbies/2013-July/008628.html which lists some. – Gilles 'SO- stop being evil' Sep 25 '21 at 08:09
  • 1
    I'm on kernel 5.4.0 and my numbers do not remotely add up. All my tmpfs filesystems from df -BK | grep tmpfs add up to 29172K but cat /proc/meminfo | grep Shmem: gives 10765236 kB. – nog642 Nov 27 '21 at 10:01