search

hzeller / gmrender-resurrect

Resource efficient UPnP/DLNA renderer, optimal for Raspberry Pi, CuBox or a general MediaServer. Fork of GMediaRenderer to add some features to make it usable.
GNU General Public License v2.0
832 stars 202 forks source link

gmrender use a lot of memory(160M) #199

Closed xiaolei0125 closed 3 years ago

xiaolei0125 commented 4 years ago

`KiB Mem : 1882232 total, 730232 free, 383052 used, 768948 buff/cache KiB Swap: 941112 total, 859192 free, 81920 used. 1405900 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 20857 root 20 0 1880292 155740 55324 S 0.7 8.3 3:47.78 gmediarender`

I used a armbian OS with 2G RAM, I found gmrender used 160M memory, why is used so much memory?

mill1000 commented 4 years ago

Whats your command line? What OS and Kernel versions?

Running master on Raspbian Stretch:

Linux raspberrypi 4.19.66-v7+ #1253 SMP Thu Aug 15 11:49:46 BST 2019 armv7l GNU/Linux

I'm seeing about 92 MB of RES at idle. 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 3692 pi        20   0  358232  92868  48444 S   0.0  9.8   0:03.24 gmediarender

Valgrind Massif is showing about 50% of the heap allocation coming from libavutil via output_gstreamer_init. I suspect due to the way gstreamer capabilities are detected.

--------------------------------------------------------------------------------
  n        time(i)         total(B)   useful-heap(B) extra-heap(B)    stacks(B)
--------------------------------------------------------------------------------
 50  1,200,950,057       81,165,640       79,061,888     2,103,752            0
97.41% (79,061,888B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
->52.05% (42,249,817B) 0x36963661: av_malloc (in /usr/lib/x86_64-linux-gnu/libavutil.so.55.78.100)
| ->51.20% (41,560,841B) 0x3696398B: av_mallocz (in /usr/lib/x86_64-linux-gnu/libavutil.so.55.78.100)
| | ->50.90% (41,314,745B) 0x35776DBC: avcodec_alloc_context3 (in /usr/lib/x86_64-linux-gnu/libavcodec.so.57.107.100)
| | | ->26.62% (21,602,328B) 0x346E3481: ??? (in /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstlibav.so)
| | | | ->26.62% (21,602,328B) 0x54B99C3: g_type_create_instance (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
| | | |   ->26.62% (21,602,328B) 0x549A746: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
| | | |     ->26.62% (21,602,328B) 0x549BEE3: g_object_new_with_properties (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
| | | |       ->26.62% (21,602,328B) 0x549C95F: g_object_new (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
| | | |         ->26.62% (21,602,328B) 0x51A95B0: gst_element_factory_create (in /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0.1405.0)
| | | |           ->26.62% (21,602,328B) 0x115802: output_gstreamer_init (output_gstreamer.c:138)
| | | |             ->26.62% (21,602,328B) 0x10EFAD: main (main.c:283)

Good news is some of the upcoming development (#194 ) drastically improves this. I'll look into a backport.

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 5239 pi        20   0   93432   8544   5792 S   0.0  0.9   0:00.23 gmediarender
xiaolei0125 commented 4 years ago

@mill1000 , Thanks for your relply. OS: Ubuntu Bionic with Armbian Linux with kernel 5.1.15-aml-s905 CMD: ./src/gmediarender -f dmr_gmr_xl --logfile=stdout --gstout-initial-volume-db=-20 --gstout-audiosink=pulsesink --gstout-audiodevice=bluez_sink.78_DA_07_FE_33_FE.a2dp_sink Then use top command to check.

I have test your code https://github.com/mill1000/gmrender-resurrect with GstreamerMemFix branch, It's very good. It works， used only 12M memory at idle. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 20392 root 20 0 634048 11432 7028 S 0.3 0.6 30:00.25 gmediarender

when gmediarender is working, it's used 60M memory
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 12086 root 20 0 1653020 57036 28932 S 4.6 3.0 0:04.84 gmediarender

But There's a small problem, when music finished to paly, gmediarender back to idle， it's still used 60M memroy, not released.

Nevertheless, it saved 100+M memory, thank you very much.

mill1000 commented 4 years ago

A quick analysis showed that the memory is mostly buffers for the Gstreamer pipeline. I am unsure if the buffers are meant to be freed when playback stops. Some quick search has indicated there may be a bug in the pipeline with regards to leaks.

Otherwise, I've found and corrected two additional leaks.

hzeller commented 4 years ago

So, looks like this can be closed ?

mill1000 commented 4 years ago

@hzeller I'd think so. @xiaolei0125 should confirm though.

mill1000 commented 3 years ago

Well someone should close this...

mill1000 commented 3 years ago

Thanks :)