Jump to content

High CPU usage 4.2.0.40


jeffu231

Recommended Posts

jeffu231

I am running the latest release server on Ubuntu 18.04.2 LTS. I am seeing high cpu usage on the embyserver process while direct streaming live tv from an HD Homerun. Both audio and video indicate they are being direct streamed. Top shows around 80% on a modern 4 core Intel machine. The ffmpeg process is very low around 1-2%. I would expect the repacking from MPEGTS to HLS to be very low cpu usage. I don't recall seeing this high usage before upgrading to 4.2. 

 

Any thoughts?

Jeff

Link to comment
Share on other sites

Could you please activate debug logging, restart the server, reproduce (only once) and post the log?

 

Thanks

Link to comment
Share on other sites

jeffu231

720 and 1080 content are about the same. If I find a SD broadcast, then the CPU drops to about 15%. I stopped watching last night and when I checked today to do this test the embyserver was stuck with 90-100% CPU. I restarted it and it dropped back down. The Dashboard did not show any activity and I don't have any outside users. One thing I did notice is that every time I restart Emby since the update, after the restart the Dashboard comes up and says restart the server to finish the updates. I have restarted Emby numerous times and the actual server as well. Not sure if this is some other bug or a indicator of what might be wrong.

 

Here are the debug logs for a 1080 broadcast. I only grabbed a few minutes. Let me know if you need more.

 

Thanks

Jeff 

embyserver_debug.txt

ffmpeg-directstream-05e9209b-c875-42cc-a72f-8ac4d7fd0653_1.txt

Link to comment
Share on other sites

jeffu231

Here is that restart message for completeness. If I refresh the browser after it appears, it goes away. This happens everytiem I restart the Emby server from the web interface. 

post-427901-0-86814500-1564869862_thumb.png

Link to comment
Share on other sites

Thanks for the new log. The only unusual behavior I could see is that the Roku is retrieving HLS segments as 1 MB chunks via range requests.

 

Could you please try to do

  • a TV recording without watching
  • watching live TV from a browser client

...and check if you're seeing the same CPU usage in these cases?

 

Thanks

Link to comment
Share on other sites

jeffu231

The embyserver process runs similarly high while recording. There is no ffmpeg process while recording. No viewing or any other activities were occurring at the same time.

 

Watching live tv from the web interface produces similar high cpu on the embyserver process. The ffmpeg process is a higher than it is when viewing on the Roku. It runs about 25%. Pausing the live stream does not change the CPU rate. I suspect this is because it is in essence recording it for time shifting, so maybe that points to the recording process with the information from the recording test.

 

I can watch a completed recording and the cpu use on the embyserver process is very low while the ffmpeg runs higher in bursts as it transcodes ahead. 

 

Jeff

Link to comment
Share on other sites

Would you mind posting the server log from the recording just so that we can try to rule out any other possible causes? Thanks.

Link to comment
Share on other sites

@@jeffu231 - Sorry for the delay.

 

I looked at your logfile and while the video recording was running there were more than a thousand log entries about library scanning.

 

Would you be able to repeat it without any library scan running at the same time, so that we can sure it isn't caused by other factors?

 

Thanks

Link to comment
Share on other sites

Thank you very much. None of those log files are showing anything unusual.

I'm afraid that there's no easy solution for this.

 

Do you have a single IPTV provider or do you have a second one to compare?

No problem though if you don't have.

 

The next step is that we'll create a beta build that allows switching off the built-in timestamp correction.

This will allow us

  • to confirm that the CPU load is caused by the timestamp correction procedures and
  • to create an unmodified recording of the raw iptv stream which we can use to reproduce processing that happens on your side
Link to comment
Share on other sites

jeffu231

 

Thank you very much. None of those log files are showing anything unusual.

I'm afraid that there's no easy solution for this.

 

Do you have a single IPTV provider or do you have a second one to compare?

No problem though if you don't have.

 

The next step is that we'll create a beta build that allows switching off the built-in timestamp correction.

This will allow us

  • to confirm that the CPU load is caused by the timestamp correction procedures and
  • to create an unmodified recording of the raw iptv stream which we can use to reproduce processing that happens on your side

 

 

I only have the one HD Homerun device to pull from. 

 

I was trying to figure out how I could attach a profiler to the process and capture what is going on. I have a lot of .NET experience, but I have never applied it to Mono/Linux, so I am not sure what the best tools are to do that. If it were a windows box, I would load up one of the profilers I have and take a look at it. 

 

I am open to helping however I can to chase it down. 

 

Jeff

Link to comment
Share on other sites

jeffu231

FYI, I upgraded to 4.2.1 and it did not change it. I could not find a change log for what was in that update.

Link to comment
Share on other sites

I could not find a change log for what was in that update.

Have you explored your server dashboard?

Link to comment
Share on other sites

jeffu231

I have, but maybe I am looking in the wrong place. The Latest news has info about an IOS update on 8/7 and the 4.2.0 update on 7/23. Nothing about 4.2.1. The you have a pending update just took me to the download site. Is there someplace else I should be looking?

Link to comment
Share on other sites

Anyway, this won't be changed in 4.2.1 as we don't know the reason for this yet. In the next beta server I will be adding a debug option for you to try to help us narrow it down. Thanks.

Link to comment
Share on other sites

jeffu231

I didn't really expect it to either, but I was just clarifying that the new version did not magically change anything. I will await further instructions on how I can help track it down.

 

Jeff

Link to comment
Share on other sites

  • 4 weeks later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...