Emby memory usage while rescanning

[averon 7]

Hello,

I'm wondering, what's a normal memory usage for Emby while rescanning libraries?

[averon 7]

Seems like Emby uses a lot of memory, while in the screenshot it is only 22GB, it peaked up to 27GB. My System only has 32GB and runs out of RAM causing CPU_IOWAIT. The OS is forced to use the disk as SWAP.

• Emby Version: 4.7.4.0
• Docker: 20.10.17
• Image: LinuxServer.io (I couldn't get your image running with GPU)
• OS: Debian GNU/Linux 10 64bit / Linux 5.10.0-0.bpo.9-amd64

What I tried:

• I ran iotop which didn't show that the disk usage was causing the CPU_IOWAIT
• Tried to set DB buffer to 1024MB
• Optimized/Vacumized the DB
• Restarted Emby
• Issue is gone, when I stop the rescan of the libraries

[Luke 42077]

Hi there, please attach the emby server log from when this happened. Thanks.

[averon 7]

Hi, will do the update first and rotate the log file. Can I PM you the log?

[Luke 42077]

Yes you can, although newer versions of the server have log anonymization features.

[averon 7]

Okay, not sure if the problem is gone now, or if the process was already almost finished. it "only" used 3.6GB this time.

I changed two things:

• Metadata readers - nfo disabled
• Markers - Generate intro video markers: as a scheduled task and when media is added -> as a scheduled task

Could that be the problem?

 

Sent logs per PM

[Luke 42077]

Hi, it is normal that the intro detection requires higher resource consumption while it is running, so yes that is possible.

[Happy2Play 9780]

6 hours ago, averon said:

Markers - Generate intro video markers: as a scheduled task and when media is added -> as a scheduled task

So you see the same result if your run the "Detect Episode Intros" task?

[averon 7]

33 minutes ago, Luke said:

Hi, it is normal that the intro detection requires higher resource consumption while it is running, so yes that is possible.

Well, it happens on task, which didn't had the same effect before, but now do. I sent you some logs and more information. I don't think that the answer "some task require a bit more performance" is the issue here. Besides the hardware is way above the emby requirements. Like I said in the DM, in 10min about 10GB of memory increase doesn't sound normal. It should be a CPU, DISK and Network (remote storage) heavy task, not memory.

[Luke 42077]

HI, please try removing the auto-organize and statistics plugins, then restart the server and see how that compares. Thanks.

[averon 7]

Hi,

Already uninstalled statistic plugin, now also removed the auto-organize plugin.

 

What I have noticed is:

• when Emby takes up so much RAM, I am unable to play anything via Embycon, it starts stuttering immediately and is impossible to watch anything, at the same time via the mobile app or web app it works just normally. (no idea why)
• when I restart/shutdown Emby via dashboard, it doesn't free-up the memory, I have to restart the container itself

 

Here my docker-compose: In case smh is wrong with it.

 

[averon 7]

Update:

While trying to figure out what could cause my issue, like testing speed between storage and emby, I decided to move emby to another stack. But the new Emby couldn't speak to the graphiccard anymore (before it worked), when using "nvidia-smi" I was notified that the driver couldn't be contacted. ... long story short, the system updated to a new kernel (5.10.0-0.bpo.12-amd64) and the headers were not installed, I installed the new headers, rebooted and the nvidia driver worked again. Now:

• emby still consumes a lot of ram:
• the memory is not used, its cached
  
• the overall performance is way better, It seems, even while running Episode Title Sequence Detection and now 15.7GB memory that I can stream again to embycon
• the IOWAIT issue is gone EDIT: Still exists, when I do Episode Audio Fingerprinting

I came up with the idea, that something else is wrong, cause of another container suddenly having the same behavior as emby, like eating all memory as cache. So right now, I am not really sure, if it's an emby error, but still I any help is apprechiated.

Cheers.

Edited June 28, 2022 by averon

[Q-Droid 989]

https://www.linuxatemyram.com/

 

[averon 7]

47 minutes ago, Q-Droid said:

https://www.linuxatemyram.com/

 

Thanks alot. This made me freak out I once though about smh, because the system didn't stall. But since my headers were missing for whatever reason, the performance was quite wacky. So I forgot about it. Thanks for clarify. Any idea about how to solve the IOWAIT?

[Q-Droid 989]

I/O wait by itself is not all that meaningful. If you think you have a storage bottleneck then utilities like sar, iostat and iotop can help identify the problem.

[averon 7]

12 hours ago, Q-Droid said:

I/O wait by itself is not all that meaningful. If you think you have a storage bottleneck then utilities like sar, iostat and iotop can help identify the problem.

Well, already used that, I guess my bottleneck is the 1Gb connection, even tho I use a bond, I didn't know that a single stream is still limited to 1Gb. Thinking about to remove the bond and using two single connections and split the apps on them. What do you think about it?

[Q-Droid 989]

A 1Gb connection for what, storage? If you're using network storage then you'll have to monitor the storage device itself. If splitting the bond reduces contention between the apps it could help. But if they're using the same storage via different paths you could still run into a bottleneck. Bandwidth is part of the equation along with IOPS and service times. Pushing the limits of what the storage can deliver for any of those introduces waits.

In the end you might be chasing a ghost that started with a false alarm - memory usage.

[averon 7]

4 hours ago, Q-Droid said:

A 1Gb connection for what, storage? If you're using network storage then you'll have to monitor the storage device itself. If splitting the bond reduces contention between the apps it could help. But if they're using the same storage via different paths you could still run into a bottleneck. Bandwidth is part of the equation along with IOPS and service times. Pushing the limits of what the storage can deliver for any of those introduces waits.

In the end you might be chasing a ghost that started with a false alarm - memory usage.

Haha, no I just noticed that the connection is limited at ~100-115MB/s so thats the 1Gb limit, and sometimes even just 80MB/s. I though if I can combine both links, to reach higher speeds. But since you explained that's not working, I decided to split the bond into two seperate connections to have a dedicated one, for emby. and yes storage.

[Luke 42077]

Hi, are you all set now?

[averon 7]

Yeah I think so, thanks.