[pulseaudio-discuss] pulseaudio - high memory usage

[Tanu Kaskinen]

On Wed, 2014-01-29 at 09:28 +0530, Arun Raghavan wrote:
> On Wed, 2014-01-29 at 00:34 +0100, Thomas Meyer wrote:
> > Hi,
> > 
> > should pulseaudio actually use that much memory?
> > 
> > $ cat status
> > Name:	pulseaudio
> > State:	S (sleeping)
> > Tgid:	1972
> > Ngid:	0
> > Pid:	1972
> > PPid:	1
> > TracerPid:	0
> > Uid:	1000	1000	1000	1000
> > Gid:	500	500	500	500
> > FDSize:	64
> > Groups:	4 6 10 11 36 63 464 468 469 500 
> > VmPeak:	 2326912 kB
> > VmSize:	 2326912 kB
> > VmLck:	       0 kB
> > VmPin:	       0 kB
> > VmHWM:	 1843468 kB
> > VmRSS:	 1843468 kB
> > VmData:	 1987020 kB
> > VmStk:	     136 kB
> > VmExe:	      80 kB
> > VmLib:	   15592 kB
> > VmPTE:	    4164 kB
> > VmSwap:	     524 kB
> > Threads:	3
> > SigQ:	0/62970
> > SigPnd:	0000000000000000
> > ShdPnd:	0000000000000000
> > SigBlk:	0000000000000000
> > SigIgn:	0000000000381000
> > SigCgt:	0000000180004a43
> > CapInh:	0000000000000000
> > CapPrm:	0000000000000000
> > CapEff:	0000000000000000
> > CapBnd:	0000001fffffffff
> > Seccomp:	0
> > Cpus_allowed:	1
> > Cpus_allowed_list:	0
> > Mems_allowed:	1
> > Mems_allowed_list:	0
> > voluntary_ctxt_switches:	12348713
> > nonvoluntary_ctxt_switches:	4858656
> 
> Have you tried interpreting what those numbers actually mean? This might
> help: http://elinux.org/Runtime_Memory_Measurement
> 
> Note that our SHM usage can cause virtual memory size look large, and
> this is a red herring.

I don't know if I read the output correctly, it looks like PulseAudio
consumes nearly 2 gigs of memory? Can SHM alone cause that?

Thomas, you could try running pulseaudio in valgrind. The command to do
that:

valgrind --leak-check=full pulseaudio --realtime=no

To get a leak report, quit pulseaudio with "pactl exit".

--realtime=no is there because otherwise, at least on my machine,
pulseaudio gets easily killed due to excessive cpu use in realtime mode.
(That sounds like a bug, btw - shouldn't rtkit just demote the
scheduling mode back to normal, not outright kill pulseaudio?)

Getting useful reports probably requires installing debug symbols for
pulseaudio first.

I tried valgrind today myself (which I do way too seldomly), and I found
one memory leak in module-card-restore, which gets triggered when
changing card profiles. I pushed a fix for that to master. There's still
one memory leak in alsa-lib, which I expect to be triggered once per
loaded instance of module-alsa-card, so it's not very serious. I didn't
bother tracking down the bug in alsa-lib.

-- 
Tanu