# What causes the sudden spike of CPU usage **URL:** \ **Category:** Issues developing apps\ **Tags:** v2\ **Created:** [March 28, 2020, 8:27am UTC](https://openvidu.discourse.group/t/what-causes-the-sudden-spike-of-cpu-usage/335 "2020-03-28T08:27:01Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![tibinpaul](https://yyz2.discourse-cdn.com/free1/user_avatar/openvidu.discourse.group/tibinpaul/32/104_2.png) [@tibinpaul](https://openvidu.discourse.group/u/tibinpaul)\ **Post date:** [March 28, 2020, 8:27am UTC](https://openvidu.discourse.group/t/what-causes-the-sudden-spike-of-cpu-usage/335/1 "2020-03-28T08:27:01Z")
Hello, I have been successfully running a session of 30 participants (Publisher: audio + video, Subscriber: audio) on 16 core CPU and the maximum CPU utilization observed was around 20%. Inspired from this data, I downsized the system to an 8 core CPU but a sudden spike in CPU utilization happened in between and the server crashed. Adding the screenshot below. ![Screenshot 2020-03-27 at 10.28.07 AM](https://global.discourse-cdn.com/free1/uploads/openvidu/original/1X/93bae928639c34a9fe00b66f2313201f88f28cd6.png) KMS log is given below. > 2020-03-27T04:07:50+00:00 – New execution > (kurento-media-server:1587): GStreamer-CRITICAL \*\*: Element rtpbin126 already has a pad named send\_rtp\_sink\_0, the behaviour of gst\_element\_get\_request\_pad() for existing pads is undefined! > (kurento-media-server:1587): GStreamer-CRITICAL \*\*: Element rtpbin659 already has a pad named send\_rtp\_sink\_0, the behaviour of gst\_element\_get\_request\_pad() for existing pads is undefined! > (kurento-media-server:1587): GStreamer-CRITICAL \*\*: Element rtpbin2336 already has a pad named send\_rtp\_sink\_0, the behaviour of gst\_element\_get\_request\_pad() for existing pads is undefined! > (kurento-media-server:1587): GStreamer-CRITICAL \*\*: Element rtpbin3589 already has a pad named send\_rtp\_sink\_0, the behaviour of gst\_element\_get\_request\_pad() for existing pads is undefined > 2020-03-27T05:02:07+00:00 – New execution > 2020-03-27T05:04:37+00:00 – New execution > (kurento-media-server:1886): GStreamer-CRITICAL \*\*: Element rtpbin37 already has a pad named send\_rtp\_sink\_0, the behaviour of gst\_element\_get\_request\_pad() for existing pads is undefined! > 2020-03-27T05:05:19+00:00 – New execution > 2020-03-27T05:08:13+00:00 – New execution > (kurento-media-server:4266): GStreamer-CRITICAL \*\*: Element rtpbin5 already has a pad named send\_rtp\_sink\_0, the behaviour of gst\_element\_get\_request\_pad() for existing pads is undefined! > (kurento-media-server:4266): GStreamer-CRITICAL \*\*: Element rtpbin524 already has a pad named send\_rtp\_sink\_0, the behaviour of gst\_element\_get\_request\_pad() for existing pads is undefined! My questions are, 1. What could cause an unexpected increase in CPU utilization? 2. Is there any useful information in Kibana related to this? Thanks in advance. ---
**Author:** ![micael.gallego](https://yyz2.discourse-cdn.com/free1/user_avatar/openvidu.discourse.group/micael.gallego/32/2_2.png) [@micael.gallego](https://openvidu.discourse.group/u/micael.gallego)\ **Post date:** [March 28, 2020, 12:05pm UTC](https://openvidu.discourse.group/t/what-causes-the-sudden-spike-of-cpu-usage/335/2 "2020-03-28T12:05:50Z")
Thank for reporting @tibinpaul. We will take care of it on Monday. ---
**Author:** ![j1elo](https://yyz2.discourse-cdn.com/free1/user_avatar/openvidu.discourse.group/j1elo/32/1516_2.png) [@j1elo](https://openvidu.discourse.group/u/j1elo)\ **Post date:** [March 31, 2020, 12:30pm UTC](https://openvidu.discourse.group/t/what-causes-the-sudden-spike-of-cpu-usage/335/3 "2020-03-31T12:30:48Z")
Hi @tibinpaul, do you have total control over the server where OpenVidu is running? I would like you to edit the file `/etc/default/kurento-media-server` and do two things: 1. Uncomment the line with `DAEMON_CORE_PATTERN`. You can leave it with the default proposed value, or change the directory to some other existing path. For example you might leave it like this: `DAEMON_CORE_PATTERN="/home/ubuntu/core_%e_%p_%u_%t"` 2. Add this new line to the end of the file: `export G_DEBUG="fatal-warnings"` With this done, restart Kurento Media Server: `sudo service kurento-media-server restart` Now, KMS **will crash immediately** after the first _GStreamer-CRITICAL_ error happens. In doing so, it will generate a **Kernel core dump** file in the path that was specified earlier. Please compress that core dump file and send it to us. As soon as you get one, you can disable the immediate crashing behavior, by commenting out or deleting the “G\_DEBUG” line. We need this core dump file in order to investigate the issue caused by all those “GStreamer-CRITICAL” messages, so it will be very helpful if you can provide one. Thanks! ---
**Author:** ![msalomon](https://yyz2.discourse-cdn.com/free1/user_avatar/openvidu.discourse.group/msalomon/32/484_2.png) [@msalomon](https://openvidu.discourse.group/u/msalomon)\ **Post date:** [May 13, 2020, 5:29pm UTC](https://openvidu.discourse.group/t/what-causes-the-sudden-spike-of-cpu-usage/335/4 "2020-05-13T17:29:51Z")
Same problem here, but i’m runnnig with +2000 users, +60 rooms and c5.18xlarge instance. ubuntu@server:/var/log/kurento-media-server$ tail -f errors.log (kurento-media-server:2042): GStreamer-CRITICAL \*\*: Element rtpbin19348 already has a pad named send\_rtp\_sink\_1, the behaviour of gst\_element\_get\_request\_pad() for existing pads is undefined! (kurento-media-server:2042): GStreamer-CRITICAL \*\*: Element rtpbin19406 already has a pad named send\_rtp\_sink\_0, the behaviour of gst\_element\_get\_request\_pad() for existing pads is undefined! (kurento-media-server:2042): GStreamer-CRITICAL \*\*: Element rtpbin19406 already has a pad named send\_rtp\_sink\_1, the behaviour of gst\_element\_get\_request\_pad() for existing pads is undefined! (kurento-media-server:2042): GStreamer-CRITICAL \*\*: Element rtpbin20876 already has a pad named send\_rtp\_sink\_0, the behaviour of gst\_element\_get\_request\_pad() for existing pads is undefined! (kurento-media-server:2042): GStreamer-CRITICAL \*\*: Element rtpbin20876 already has a pad named send\_rtp\_sink\_1, the behaviour of gst\_element\_get\_request\_pad() for existing pads is undefined! ---
**Author:** ![micael.gallego](https://yyz2.discourse-cdn.com/free1/user_avatar/openvidu.discourse.group/micael.gallego/32/2_2.png) [@micael.gallego](https://openvidu.discourse.group/u/micael.gallego)\ **Post date:** [May 15, 2020, 6:25pm UTC](https://openvidu.discourse.group/t/what-causes-the-sudden-spike-of-cpu-usage/335/5 "2020-05-15T18:25:00Z")
Hello Matías, If your KMS crashed, please follow these instructions to help us to know the root cause of the problem: [https://docs.openvidu.io/en/2.14.0/deployment/deploying-on-premises/#kurento-media-server-crash](https://docs.openvidu.io/en/2.14.0/deployment/deploying-on-premises/#kurento-media-server-crash) ---
**Author:** ![msalomon](https://yyz2.discourse-cdn.com/free1/user_avatar/openvidu.discourse.group/msalomon/32/484_2.png) [@msalomon](https://openvidu.discourse.group/u/msalomon)\ **Post date:** [May 22, 2020, 8:04pm UTC](https://openvidu.discourse.group/t/what-causes-the-sudden-spike-of-cpu-usage/335/6 "2020-05-22T20:04:58Z")
No crash, just spike of CPU usage. Right now I’m using differents instance for each school and it works fine. I looks like four c5.4xlarge are better than just one c5.24xlarge (and cheapper). ---
**Author:** ![micael.gallego](https://yyz2.discourse-cdn.com/free1/user_avatar/openvidu.discourse.group/micael.gallego/32/2_2.png) [@micael.gallego](https://openvidu.discourse.group/u/micael.gallego)\ **Post date:** [May 22, 2020, 8:27pm UTC](https://openvidu.discourse.group/t/what-causes-the-sudden-spike-of-cpu-usage/335/7 "2020-05-22T20:27:53Z")
More small machines are better than just one big machine if your use case allow it. We have detected a performance problem in some operations in Kurento Media Server. We have published a beta version that we hope fix the problem. Can you test it and provide feedback? > > > Prerequisites > > I have read the SUPPORT document > > I have checked the Troubleshooting Guide > > I have tested with the latest version of...