After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 749836 - Gstreamer Queue element. Gstreamer with Kurento media server CPU leak.
Gstreamer Queue element. Gstreamer with Kurento media server CPU leak.
Status: RESOLVED NOTABUG
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
unspecified
Other Linux
: Normal critical
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-05-25 14:18 UTC by Azer Guliev
Modified: 2015-05-25 14:33 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Top (300.45 KB, image/png)
2015-05-25 14:18 UTC, Azer Guliev 		Details

Description Azer Guliev 2015-05-25 14:18:21 UTC 
Created attachment 303925 [details]
Top

Hello.

We are using Kurento media server, which is built on top of Gstreamer.

Webrtc-webrtc.

We are testing about 6-7 viewers with a single master with one to many scenario and getting the following output on processor with top, can you please help us understand what is this fork queue doing while the fork rtp-session is running only 0.3% of cpu each and queue is running 5% of cpu each?

Server specs: 

Server: Dual E5-2620 v3 (6 Cores, 2.40 GHz)
Second Processor: E5-2620 v3 (6 Cores, 2.40 GHz)
Os: Ubuntu Linux 14.04 LTS Trusty Tahr (64 bit)
Ram: 32 GB RAM

Is it gstreamer's queue element?
Is there a way to decrease cpu usage?
Comment 1 Tim-Philipp Müller 2015-05-25 14:33:41 UTC 
This is more of a support question than a bug report. Please ask for support either in the Kurento forum or mailing list or on the gstreamer-devel mailing list.

In order to figure out where CPU is spent you should probably apply more sophisticated techniques than 'top'. At least use 'perf top' :)

It's not the queue element per se using up this much CPU, it just means some elements running in the thread driven by the queue's source pad thread is taking up CPU. This could be encoders or converters or mixers for example.