Emby server memory usage

[parrish 18]

This memory leak (at least in my case) is definitely due to DLNA.  I disabled DLNA about 3 hours ago and the Emby Server memory usage is tiny- only about 99mb ever since.  It's actually dropped down from about 180mb from when I first started it.  Any idea what DLNA setting might be at fault or at play in this issue?  The two I'm thinking might have an impact are DLNA Play To and Blast Alive messages (well those are the only other options besides enabling DLNA itself).  

What impact will there be in DLNA usage if I leave both of those options disabled?

Edited July 19, 2017 by parrish

[Luke 37008]

I think it is device specific. If you look at your log, one of the devices on your network is hammering your emby server with requests. Why - it could be a bug in that device's dlna software. It also could be that some other response from Emby is not what the device expects and it is causing it to get confused in some way.

 

The user agent it reports is blank but try to find the device on your network at

10.100.90.124

[parrish 18]

 

I think it is device specific. If you look at your log, one of the devices on your network is hammering your emby server with requests. Why - it could be a bug in that device's dlna software. It also could be that some other response from Emby is not what the device expects and it is causing it to get confused in some way.

 

The user agent it reports is blank but try to find the device on your network at

10.100.90.124

 

That is the Dish Hopper3.  The Joeys associated with that Hopper are the other devices showing up with those similar entries in that log.  So far, with both DLNA Play To and Blast Alive turned off (but with DLNA server active) the RAM usage is not increasing- but it has only been about 15 minutes so a bit too premature to tell.  The logs still have those same entries coming from the Dish Network devices.  None of the Dish Network devices are currently in use (be it streaming DLNA or even turned on to watch TV). 

[TonkaTuff 6]

OK, I've been running for about 24 hours now and the problem has not occurred. Previously it probably would have by now.

Looks like its a plugin problem.

What's the next move?

Start installing them one by one and seeing if/when the problem starts again, I guess?

Cheers.

[Luke 37008]

Thanks for the feedback.

[parrish 18]

It's been almost 24 hours since I disabled Play To and Blast Alive in the DLNA settings and memory usage has not increased at all.  It's staying at around 100mb.  So there is something with either Play To or Blast Alive that is causing the memory leak.  I'll try turning one of the settings on at a time and letting it run over night to see if I can pinpoint which of those two is at fault. 

[Luke 37008]

Yea for some reason your dish hopper is hamming the server with repeated http requests.

[Untoten 295]

I do not have that plugin so I am still analyzing my issue, interesting that our problems started occuring at the same time though, this is new for me in the past 2-3 months.

[Untoten 295]

@@Luke is there a way to limit log size?  I have disabled debugging but these logs are still hitting ~9gb which is causing parsing issues.

Edited July 20, 2017 by Untoten

[parrish 18]

Same here, Untoten.  I had no memory usage issues until the last 2 or 3 updates.  I've had Dish Hopper and Joeys for years- before I even started using Emby.  I do agree that there is something going on with Dish in how it keeps sending http requests to the DLNA server- I don't like that.  But I don't think it's the cause of this memory leak.  

[Guest asrequested]

Your hopper also gets software updates. So there may be a change that could cause that, which wasn't present, before. I used to install them. Though it's been along time.

[jnheinz 17]

Just throwing in my 2 cents.. As of the most recent update, I also see it come to a crawl.. I check Resource Monitor, and it's pegged at 99% memory utilization.  This was not an issue in previous Emby Server for Windows releases.  This has happened four times since I updated to 3.2.24.

 

I will try to attach some logs here when able, as I just rebooted the VM.

 

EDIT: I checked the server logs for the past 2 days, and it looks like I left the Emby Server Dashboard up on another VM on the Scheduled Tasks page.  Every 5 seconds, it has one of these entries in the log.  It's like it is "checking in" every 5 seconds religiously.  I replaced my server name with xxx.xxx.

 

2017-07-19 14:06:09.7382 Info HttpServer: HTTP Response 200 to 10.0.0.28. Time: 0ms. http://xxx.xxx.com:8096/emby/ScheduledTasks?isHidden=false
2017-07-19 14:06:14.7382 Info HttpServer: HTTP GET http://xxx.xxx.com:8096/emby/ScheduledTasks?isHidden=false. UserAgent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36

 

It is difficult to paste the "applicable time frame" on a memory leak, as its applicable time frame is from service restart or system restart to the memory leak detection.  Do you want every day of logs from the last time I restarted the system?  I think it's only averaging about 3-5 days before I find the memory leak.

 

Attached is a screenshot of the VMware vSphere Client, Performance View of the Memory performance (defaults).  I applied the update during on July 10th & rebooted.  Those wild swings occurring after July 11th were not present if I pull a 3 month or 6 month graph.  I don't know what to look like if the logs are empty besides that entry above.

 

Edited July 21, 2017 by jnheinz

[jnheinz 17]

I have disabled all DLNA functionality as a precaution (I don't use it), and I have closed that tab on that browser.  Those are the only two changes I am making as a test.

 

Here is a more granular picture of the past 24 hours.  It looks as if it is pulling a lot of memory & releasing it quite frequently.  Would this be expected?

 

 

I feel like the web server itself should able to sustain a request every 5 seconds?  This does not seem excessive to me.  That is the only common thing I can find.  You had a Dish Hopper hitting it frequently, and I have a tab of Google Chrome hitting it frequently.  Hammering?  I do not consider that hammering.  Multiple requests a second for a week?  Maybe, I guess.  There was virtually no activity occurring on the server at all until ~7:30PM this evening where the spike got more vicious & made Emby unresponsive, prompting the reboot.

Edited July 21, 2017 by jnheinz

[Untoten 295]

I have disabled all DLNA functionality as a precaution (I don't use it), and I have closed that tab on that browser.  Those are the only two changes I am making as a test.

 

Here is a more granular picture of the past 24 hours.  It looks as if it is pulling a lot of memory & releasing it quite frequently.  Would this be expected?

 

 

I feel like the web server itself should able to sustain a request every 5 seconds?  This does not seem excessive to me.  That is the only common thing I can find.  You had a Dish Hopper hitting it frequently, and I have a tab of Google Chrome hitting it frequently.  Hammering?  I do not consider that hammering.  Multiple requests a second for a week?  Maybe, I guess.  There was virtually no activity occurring on the server at all until ~7:30PM this evening where the spike got more vicious & made Emby unresponsive, prompting the reboot.

I suspected the chapter image extraction as the culprit but I cannot pinpoint it.  Is this perhaps wht you suspect as well?  I figure it is grabbing all the images and keeping them in RAM until it commits them.  But still, I have 16GB of RAM just for emby, this is nuts even if it is images.

[jnheinz 17]

I suspected the chapter image extraction as the culprit but I cannot pinpoint it.  Is this perhaps wht you suspect as well?  I figure it is grabbing all the images and keeping them in RAM until it commits them.  But still, I have 16GB of RAM just for emby, this is nuts even if it is images.

This is a good hypothesis.  I do use chapter image extraction, and I have pretty extensive collection that it is running against.  It is running every morning & claims to run for about 5-10 minutes.  It was not an issue prior to 3.2.24, although I may have not been on 3.2.22 long.  It is difficult to tell what it is.  I will turn on debug logging.

[Untoten 295]

This is a good hypothesis.  I do use chapter image extraction, and I have pretty extensive collection that it is running against.  It is running every morning & claims to run for about 5-10 minutes.  It was not an issue prior to 3.2.24, although I may have not been on 3.2.22 long.  It is difficult to tell what it is.  I will turn on debug logging.

I even did a fresh server install, with no plugins except backup restore (only restored users) and it still did this, which makes me think it's an OEM problem.  Also, it took about a week to even have all the shows add because library scans can take 3-5 days.

[aspdend 174]

OK, I've been running for about 24 hours now and the problem has not occurred. Previously it probably would have by now.

Looks like its a plugin problem.

What's the next move?

Start installing them one by one and seeing if/when the problem starts again, I guess?

Cheers.

If you haven't already - do try installing them one at a time - personally I would try installing the others before Cover Art as, in my experience, that's the plugin that causes most issues

[TonkaTuff 6]

I've gone the other way and re-installed only Cover Art (thinking that this might make the problem occur). So far it's running fine but memory use is creeping up. It's at 680MB now and not dropping. I'll give it a few more days to confirm either way before proceeding to install another one.

It will be  pity if I can't use Cover Art any more; I love it.

[pir8radio 1292]

I have disabled all DLNA functionality as a precaution (I don't use it), and I have closed that tab on that browser.  Those are the only two changes I am making as a test.

 

Here is a more granular picture of the past 24 hours.  It looks as if it is pulling a lot of memory & releasing it quite frequently.  Would this be expected?

 

 

I feel like the web server itself should able to sustain a request every 5 seconds?  This does not seem excessive to me.  That is the only common thing I can find.  You had a Dish Hopper hitting it frequently, and I have a tab of Google Chrome hitting it frequently.  Hammering?  I do not consider that hammering.  Multiple requests a second for a week?  Maybe, I guess.  There was virtually no activity occurring on the server at all until ~7:30PM this evening where the spike got more vicious & made Emby unresponsive, prompting the reboot.

 

 

That is strange, my server shows a completely different picture.  Are your graphs of the emby application ONLY or your whole pc?  Mine are for emby application only.  It actually peaks at 4am every day, which is when most of my scheduled tasks happen but then starts to level off..

 

 

Edited July 21, 2017 by pir8radio

[jnheinz 17]

That is a much different picture.  Mine is of the whole VM, but Emby Server is literally the only thing installed.

 

Here is a graph this morning after disabling DLNA & closing the stray Google Chrome tab left up on Scheduled Tasks.  This looks much more normal.

 

[Untoten 295]

@@Luke this is becoming a widespread issue, updates?  This is the 9th time I had to reboot my server in 2 weeks due to unresponsiveness of the server because of memory consumption.

EDIT: Just disabled DLNA as suggested by other users, I will update with results.  (May take 24-48 hours)

Edited July 22, 2017 by Untoten

[Luke 37008]

Best thing to do is see post #10. Thanks.

[jnheinz 17]

@@Luke this is becoming a widespread issue, updates?  This is the 9th time I had to reboot my server in 2 weeks due to unresponsiveness of the server because of memory consumption.

 

EDIT: Just disabled DLNA as suggested by other users, I will update with results.  (May take 24-48 hours)

 

I will chime in here, as I am following this thread & encountering similar frustrations recently.  I disabled DLNA & closed some stray Emby Server Dashboard-related tabs -- been 48 hours now almost.  Here is my graph.  Relatively light traffic on it since, but it is pretty normal usage.  The issue has happened in anywhere from 2-7 days, so it's difficult to declare victory yet.

 

 

[parrish 18]

Best thing to do is see post #10. Thanks.

 

Luke, I'm sorry, but that is a very poor answer as what that post links to- the How to report a problem page of the forum- is exactly what this thread is.  Anyone that reads that post will quickly realize the only thing it actually says to do is to start a new discussion (what this thread is) and post server logs- which I have done. When that gets no real response other than a general acknowledgement that a post was made (if that) then what else are we to do?  To be sure, we aren't talking about a commercial product that has near unlimited financial and technical resources being thrown at it but many of us do pay for the Emby Premier subscription to help support the project- so it's not unrealistic for many of us to expect that certain questions be taken seriously. Especially in regards to a pretty severe bug such as a memory leak. 

 

By the way, as an update to my own server, I re-enabled both the 'Enable DLNA Play To' and Enable DLNA server but have left 'Blast Alive Messages' disabled.  So far, after a number of days, memory usage has stayed at about 100mb.  That said, I have not streamed any media during that time either.  I will next try enabling Blast Alive Messages and see if memory usage begins to increase again.   What's interesting to note is that, with Blast Alive Messages disabled, I am no longer getting those continuous entries in the Emby logs from my Dish Hopper and Joeys.  So I suspect something isn't jiving between whatever Blast Alive Messages does and Dish. 

[Luke 37008]

That response was not for you, only to post #46. Thanks.