neko icon indicating copy to clipboard operation
neko copied to clipboard

neko process uses ~80% CPU while idling

Open 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

djmaze avatar Jan 01 '21 16:01 djmaze

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

GigaFyde avatar Jan 01 '21 16:01 GigaFyde

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

djmaze avatar Jan 01 '21 16:01 djmaze

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

GigaFyde avatar Jan 01 '21 16:01 GigaFyde

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.

djmaze avatar Jan 01 '21 16:01 djmaze

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

GigaFyde avatar Jan 01 '21 16:01 GigaFyde

I can indeed reproduce on nurdism/neko:firefox

Personally I've been using m1k1o/neko:latest

GigaFyde avatar Jan 01 '21 16:01 GigaFyde

I suppose that one is built from your dev branch?

djmaze avatar Jan 01 '21 17:01 djmaze

You would have to ask @m1k1o yourself

GigaFyde avatar Jan 01 '21 17:01 GigaFyde

Oops, how did I make that connection ;)

djmaze avatar Jan 01 '21 17:01 djmaze

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

m1k1o avatar Jan 01 '21 17:01 m1k1o

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 ;)

djmaze avatar Jan 01 '21 17:01 djmaze

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

djmaze avatar Jan 01 '21 17:01 djmaze

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.

m1k1o avatar Jan 01 '21 17:01 m1k1o

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

djmaze avatar Jan 01 '21 18:01 djmaze

@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.

m1k1o avatar Jan 01 '21 19:01 m1k1o

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

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)

gbrian avatar Feb 25 '21 17:02 gbrian