neko process uses ~80% CPU while idling

Question

neko process uses ~80% CPU while idling

djmaze opened this issue 4 years ago · 16 comments

Is your feature request related to a problem? Please describe.
Running the container (nurdism/neko:firefox) on my server, I realize it always uses about 85-90% of one CPU core, even if there is no one connected to the session.

Describe the solution you'd like
I guess the load is that high because video / audio encoding is permanently active. So as long as no one has logged in or after the last person has logged out, the encoding should automatically be paused.

Describe alternatives you've considered
–

Answer 1 · 2021-01-01T16:26:57.000Z

Pretty sure this was implemented ages ago,
Sounds a lot more like firefox/chrome taking up cpu instead

Answer 2 · 2021-01-01T16:36:29.000Z

Running top inside the freshly started container shows me that the neko process uses 80% CPU while everything else stays close to 0.

Answer 3 · 2021-01-01T16:38:36.000Z

Pretty sure you also noticed that that jumps significantly when you do connect to neko

Answer 4 · 2021-01-01T16:50:47.000Z

Yeah, when connected it seems to go a bit over 100% depending on what is happening in the session, but not much more.

So is idling at 80% CPU expected behaviour? If yes, why is it that high?

I should probably have added that I am using the nurdism/neko:firefox image with the compose file from the repo.

Answer 5 · 2021-01-01T16:52:58.000Z

Lemme see if I can reproduce with that image,
Since on my install it does drop down to 0% usage

Answer 6 · 2021-01-01T16:54:41.000Z

I can indeed reproduce on nurdism/neko:firefox

Personally I've been using m1k1o/neko:latest

Answer 7 · 2021-01-01T17:08:10.000Z

I suppose that one is built from your dev branch?

Answer 8 · 2021-01-01T17:08:56.000Z

You would have to ask @m1k1o yourself

Answer 9 · 2021-01-01T17:12:56.000Z

Oops, how did I make that connection ;)

Answer 10 · 2021-01-01T17:13:32.000Z

@djmaze yes. I kept my master branch in sync with original repository and made my changes in dev branch.

Answer 11 · 2021-01-01T17:19:54.000Z

So the question is if there is a tangible reason for this behaviour in the nurdism version or if the image build is somehow borked. I can e.g. see that your fork does not use a custom gstreamer build, so it does not seem to be needed anymore. Either way, I might as well switch to your version then, so thanks ;)

Answer 12 · 2021-01-01T17:33:51.000Z

Confirming that when using m1k1o/neko:latest, the neko process stays below 1% of CPU when idling.

Answer 13 · 2021-01-01T17:42:35.000Z

I guess, the reason can be just old image on docker hub. nurdism/neko:firefox was last updated 9 months ago. At that time, that feature might have not even been implemented and pipelines were always running. nurdism/neko:latest was updated 2 months ago, that might work as expected.

Answer 14 · 2021-01-01T18:53:52.000Z

Okay, and latest is always a firefox image? I can't discern that from the build script.

Answer 15 · 2021-01-01T19:18:11.000Z

@djmaze yes, both in my and nurdism's. There is also m1k1o/neko:chromium available. In nurdism's too, but that one has not been updated for a while. My fork uses ungoogled chromium with h265 support.

Answer 16 · 2021-02-25T17:08:39.000Z

Hi,
Thanks @djmaze for opening this issue and @GigaFyde and @m1k1o for spoting about old version of images.
Some graphs from m1k1o/neko:latest

Original images from nurdism are not working with my current configuration*.
Thanks @m1k1o I'll be following your work to see if I can help as I'm testing on serving multiple neko rooms

*Server conf
www.hetzner.com/cloud server
CPX31 4VPC 8GB RAM (Ubuntu)