Emby server memory usage

[Happy2Play 9780]

Any Windows users tried NSSM and created a service to see if it performs any any better?  Since that is how the dotnet versions service will be made.

[Luke 42077]

It shouldn't have any impact, but obviously feedback is nice.

[Luke 42077]

Regarding the .net core version we're testing:

 

 

The best thing so far is that the memory usage is so low on the other beta which I have removed I couldn't record two hd channels at the same time without crashing other applications as it was using all the memory. 

 

[RedBaron164 18]

Just wanted to update on what I've been seeing with my install. I am still running version 3.2.30.0 as a service. I have not rebooted the service or the server at all in over a week. Emby's memory usage has been sitting between 1.5gb and 1.75gb.  And while that is higher than the 400mb I have historically seen Emby use when it's idle, it seems to be stable and not continuously increasing and running the server out of memory.

[TheHwyman 5]

Update from my side of things...

 

Been 3.5 days since my last post on Monday. My buddy rebuilt his messed up Windows Kodi client and my Emby service has been running with stable memory use since Monday, averaging 700 - 850 mb usage. No client errors in the server logs since Monday.

[pir8radio 1312]

so how close is this to being released stable? I'm pretty excited...   Still sounds a little ways off.... Just curious.  Oops thought i was on the .net core thread still.

Edited September 15, 2017 by pir8radio

[BloodyIron 24]

@@Luke @@ebr, any chance we could get a "rebuild database" job perhaps? Seems like a good debug task, even though I anticipate it could still have a long complete task. Seems like lexisdude may be on to something for some cases.

 

 

For what its worth.

I was having these type of problems. Extreme amounts of memory usage - system slowing down to a crawl; taking a very long time to load screens in the web browser and on my roku devices. Ended up being a corrupt or skewed database - even though I was not getting any database errors I was seeing timeouts because of the length of time it was taking between requests and commands to the server. To fix I changed from a centralized database ; to data and images being saved to the directories - turned off all plugins ; rebuilt by database; turned plugins back on and all problems disappeared. Now I am seeing 2 second or less turnaround times for everything - and no memory issues. Not saying this is your specific problem - but my issues started up without warning and no specific errors in debug logs which pointed me into the right direction. My database before the switch was about 14 gigs in size - which is a lot of data to scan through when the system was processing requests. Its about 700 megs now with the same amount of content

[BloodyIron 24]

Also, I am seeing a pretty tangible memory leak for Linux, working on putting the report together right now. Seems to grow 100-200MB/day. I can tell from my monitoring software, and how much the SWAP growth is

 

My report : https://emby.media/community/index.php?/topic/50912-memory-leak-ubuntu-1604/

Edited September 16, 2017 by BloodyIron

[BloodyIron 24]

Oh, and can we PLEASE have the report bugs thread talk about where the LINUX log files are too? I seriously can't find that documented anywhere.

[Jdiesel 1431]

Oh, and can we PLEASE have the report bugs thread talk about where the LINUX log files are too? I seriously can't find that documented anywhere.

You can see the path on your server dashboard page.

[BloodyIron 24]

That isn't a good reason to not document it in a thread literally intended for documenting where it is : https://emby.media/community/index.php?/topic/739-how-to-report-a-problem/

 

BUT! I appreciate you pointing that out to me anyways

 

 

You can see the path on your server dashboard page.

[Luke 42077]

Please try Emby Server 3.2.31.

 

Later, the move to .NET Core will bring more dramatic improvements, but we are not yet ready to switch our existing installations over to that. It can be tested separately though.

 

Thanks !

[BloodyIron 24]

Is that still going to be available on Linux? Any sort of target timeline you are considering for such a conversion?

 

 

Please try Emby Server 3.2.31.

 

Later, the move to .NET Core will bring more dramatic improvements, but we are not yet ready to switch our existing installations over to that. It can be tested separately though.

 

Thanks !

[Luke 42077]

If you're asking about the new stable release, it's already available. 

 

If you want to try Emby Server on .net core, you're welcome to jump into the testing thread for it here:

 

https://emby.media/community/index.php?/topic/50012-emby-server-for-net-core/

 

Thanks.

[RedBaron164 18]

I updated to version 3.2.31 yesterday and after about 24 hours my memory usage is just under 1gb.

[Happy2Play 9780]

I updated to version 3.2.31 yesterday and after about 24 hours my memory usage is just under 1gb.

 

So is that good or bad?

[Untoten 306]

Reinstalled my whole OS after physically replacing all my RAM with new RAM I just ordered.  It was fine until it got to about70% library scan, now I am hitting 14gb or RAM usage regularly. SO it was not my OS, it was not my RAM.  

I am also currently on the .21 release

Edited September 22, 2017 by Untoten

[Happy2Play 9780]

Reinstalled my whole OS after physically replacing all my RAM with new RAM I just ordered.  It was fine until it got to about70% library scan, now I am hitting 14gb or RAM usage regularly. SO it was not my OS, it was not my RAM.  

 

I am also currently on the .21 release

 

That is a rather old version

[revengineer 142]

That is a rather old version

Agreed. Lately, Luke and team are making continuing effort to get to the ground of this. Reporting any memory issues from anything but the latest version is not very useful.

 

I have updated to v3.2.32 today and will be monitoring about the next weeks. I did make a change today to store meta data with movie files; not to check whether this reduces memory leak but because I wanted to do this for a while.

[Untoten 306]

That is a rather old version

I meant .31, my mistake.

[BloodyIron 24]

Still monitoring the situation on my end, not a long enough timeframe just yet to give useful feedback as there is everyday fluctuations in the RAM being used due to me actually using it

 

How much RAM should Emby be using when idling?

Edited September 24, 2017 by BloodyIron

[revengineer 142]

How much RAM should Emby be using when idling?

It depends on your setup. Look for steady and unusual memory growth. Mine is about 100 MB/day, but others have reported values much more significant (in the GB range and within a very short time). Since my growth is not very large, I need about two weeks for testing. Once I get to >2 GB I will call this unusual because today emby works just fine on a fraction of that threshold.

[RedBaron164 18]

I updated to 3.2.32.0 when it was released on Friday (9-22) and my memory usage is up to 1.9gb already. I'll keep an eye on it but what I've been noticing is that for me, Emby will run up to about 1.8gb-2gb of memory usage, and be "stable" for about a week or two, and then I will get "Resource Exhaustion" Warnings in my system log and then Emby will crash. At which point I have the service set to restart automatically.

[BloodyIron 24]

Currently htop reports about 2.3GB is being used by Emby in idle. From what I can tell that is the RAM the application is using, not the RAM the Linux kernel is caching.

 

Looking at historical charts for the last bunch of days (half week?). The memory usage SEEMS to be stable, but I am going to continue monitoring it.

 

I'm clamping myself to 3.2.31.0 until I have more data that is longer-term (a week-2 or so), as updates/restarting of Emby will spoil the test results in this case.

[revengineer 142]

Currently htop reports about 2.3GB is being used by Emby in idle. From what I can tell that is the RAM the application is using, not the RAM the Linux kernel is caching.

 

I was not aware of memory leak issues on Linux. I thought we are solely discussing the Windows version here.