5

I invoked the top command and got this:

 PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                  
3433 klutt     20   0 4790760   1.0g 282208 S   8.3   4.2   1261:15 firefox-esr              
2063 klutt      9 -11 3424532  33644  24432 S   7.0   0.1 432:44.69 pulseaudio               
3681 klutt     20   0 3958364 545000 139800 S   6.6   2.2 434:35.72 Web Content

I understand that firefox and Web content are using a lot of memory, but pulseaudio? Is it normal that it is using over 3GB? Is it a bug?

$ uname -a
Linux desktop 5.7.0-1-amd64 #1 SMP Debian 5.7.6-1 (2020-06-24) x86_64 GNU/Linux

$ pulseaudio --version
pulseaudio 13.0


$ cat /etc/debian_version 
bullseye/sid
Jeff Schaller
  • 67,283
  • 35
  • 116
  • 255
klutt
  • 544

3 Answers3

17

In your example, pulseaudio is using 32MB not 3GB. The RES column is physical memory. The VIRT column shows all the virtual memory used by the process. According to man top, that includes all code, data, and shared libraries plus pages that have been swapped out and pages that have been mapped but not used.

Artem S. Tashkinov
  • 29,025
Andy Dalton
  • 13,993
  • Doesn't most leaked memory eventually get swapped out when the program stops using that memory and then would show up under VIRT? – Segfault Jul 20 '20 at 17:55
  • 5
    @Segfault sometimes but not always. In this case though, a 3G VSS is normal for Pulseaudio, it allocates a big chunk of memory at startup and then does it's own memory management internally to avoid the (extreme) overhead of malloc() and free(). This is a rather standard technique for memory-management intensive applications that require upper bounds on worst-case latencies because libc-provided memory management routines are insanely slow. – Austin Hemmelgarn Jul 20 '20 at 18:29
  • 1
    But RES is not a good measure either, is it? If you only have 32 MB of RAM, it will never climb over 32 MB. – Thomas Weller Jul 21 '20 at 07:09
  • @ThomasWeller yes, true. But apparently there is no good and simple measure for memory usage under Linux. See eg. https://unix.stackexchange.com/questions/34795/correctly-determining-memory-usage-in-linux for some details on the topic. – oliver Jul 21 '20 at 17:21
  • @AustinHemmelgarn the overhead of malloc and free is not extreme, but maybe it is a little unpredictable, and PulseAudio needs consistency. In fact "allocate a big chunk of memory and manage it" is exactly what malloc and free already do! – user253751 May 22 '23 at 15:03
7

You can see more details on the virtual memory usage using the pmap tool:

pmap $(pidof pulseaudio) | sort -hk 2

00005590f6f0a000      4K r---- pulseaudio
00005590f6f0b000      4K rw--- pulseaudio
00007f50ea53f000      4K r---- libicudata.so.66.1
00007f50ea540000      4K r-x-- libicudata.so.66.1
....
00007f50e0000000  65536K rw-s- memfd:pulseaudio (deleted)
00007f50f314b000  65536K rw-s- memfd:pulseaudio (deleted)
 total          1679768K

For me, most of the memory used is 64MB memfd buffers. memfd is a method of communicating between processes, and it is used by applications to transfer audio data to pulseaudio.

Even though the virtual memory for the buffers is allocated for each application, actual memory is only used to the amount of data currently in transit. When application writes audio samples to the buffer, memory is allocated for it. Once pulsaudio has mixed and played the samples, the memory is again released.

jpa
  • 1,269
0

As others have answered, the virtual memory size shouldn't matter for RAM consumption. If for other reasons you still want to reduce the virtual memory size of pulseaudio and its client processes:

Find your pulseaudio daemon config (most likely /etc/pulse/daemon.conf) and uncomment and change the setting enable-shm as such:

enable-shm = no

Then reboot your machine, or restart pulseaudio with

systemctl --user restart pulseaudio

This will not give you any real memory savings and will cause imperceptible performance overhead, but the virtual memory usage will go down and you will gain peace of mind!

jimis
  • 162