High RAM usage on Emby Server 4.9.3.0 even with Direct Play and rclone mounts

[jordan888 6]

Hello,

 

I'm experiencing high RAM usage on my Emby server and would like to know if this is expected behavior or a configuration issue. To free up memory, I have to restart the service, but now it increases again. This happens after the server update.
 

Server environment

• OS: Linux (VPS)

• RAM: 8 GB

• Emby version: latest stable

• Storage: rclone mounts (Google Drive / cloud storage)

• Streaming mode: Direct Play (no transcoding)

• Concurrent streams: 2–4 users

Observations

• EmbyServer process uses between 1.2 GB and 5.8 GB of RAM.

• rclone mount processes use relatively little RAM (20–60 MB each).

• No transcoding is happening (Direct Play only).

• Database cache size was set to 1024 MB and reduced to 256 MB (after restart).

• System cache (Linux cached memory) is around ~1.7 GB.

• Even with low activity, Emby memory usage remains high.
  
  
   

  free -h
  Mem: 7.8Gi total, 5.8Gi used, 1.6Gi available

  ps aux --sort=-%mem
  EmbyServer: ~5.6 GB RSS (~70% RAM)
  rclone mounts: ~20–60 MB each
  
   

  Question

•  Is this level of RAM usage normal for Emby with rclone mounts?

• Does Emby aggressively cache metadata or media files in memory?

• Are there recommended settings to limit Emby memory usage?.

•  

• Could plugins or library scans cause this behavior?

• Is there any way to cap Emby RAM usage (for example via configuration or systemd)? 

  
  Any guidance or best practices would be appreciated.
  Thank you

embyserver (2).txt

[seanbuff 1365]

@sa2000

[Luke 42414]

Hi, what makes you think it’s direct play only? There is some transcoding in this log file.

[sa2000 731]

On 30/01/2026 at 19:51, jordan888 said:

Database cache size was set to 1024 MB and reduced to 256 MB (after restart)

I would suggest running at default setting as the cache is now per db connection and with 5 library.db connections that would be over 1Gb just for the library.db cache. We also have a fixed 64Mb cache per db connection for the other db's which potentially be another 700Mb

So I suggest changing the cache to 128Mb which is the current default per library.db connection

It has also been seen that repeated all libraries scans could lead to memory use climbing  - so interval between scheduled task triggers for "Scan Media Library" should not be low. Suggest having real time monitoring for libraries and the periodic all libraries scans set to perhaps weekly

 

Edited February 2 by sa2000

[jordan888 6]

12 hours ago, Luke said:

Hi, what makes you think it’s direct play only? There is some transcoding in this log file.

Hi Luke, thanks for replying. 
The streams are usually done via DirectPlay. I have a user who transcodes. 
The thing is, when monitoring the server, even when no one is playing or at least only one person is, and after restarting the service, the memory usage is almost 80% after 20 hours. 
That's what I find strange. I've changed the cache size back to 128 as suggested by sa2000. Thanks for your attention to this issue. 
I'll send the results in a few days. For now, the only thing I can do is set up a cron job to restart the service approximately every 24 hours; otherwise, everything crashes due to excessive RAM usage, 
and I don't want to set RAM limits yet until I understand this better. Thanks.

[jordan888 6]

2 hours ago, sa2000 said:

I would suggest running at default setting as the cache is now per db connection and with 5 library.db connections that would be over 1Gb just for the library.db cache. We also have a fixed 64Mb cache per db connection for the other db's which potentially be another 600Mb

So I suggest changing the cache to 128Mb which is the current default per library.db connection

It has also been seen that repeated all libraries scans could lead to memory use climbing  - so interval between scheduled task triggers for "Scan Media Library" should not be low. Suggest having real time monitoring for libraries and the periodic all libraries scans set to perhaps weekly

 

Thanks SA2000 for your reply and suggestion. I've implemented what you mentioned to reduce the database cache to 128MB and I'm monitoring it, but I'd like to understand your point a bit better. When you say "cache per .db," do you mean all the .db files in the /var/lib/emby/data folder? I currently have 12 libraries, and I'm not sure if the cache is per library when you say "per .db."

[sa2000 731]

On 31/01/2026 at 14:43, jordan888 said:

When you say "cache per .db," do you mean all the .db files in the /var/lib/emby/data folder? I currently have 12 libraries, and I'm not sure if the cache is per library when you say "per .db."

It is per .db file and each .db file can have multiple connections up to a set maximum

We have these databases: authentication.db, activitylog.db, users.db and library.db.

The cache is defaulted as 128Mb per connection for the library.db and hard wired at 64Mb for each of the connections to the other db's

We can have up to 5 connections for each of the library.db and authnetication.db and up to 3 connections for each of the remaining 2 databases. So  with the defaults, the max cache Mb usage could be 640Mb for the library.db and 704Mb for the other 3 db files.

 

So maximum 

Edited February 2 by sa2000

[jordan888 6]

21 hours ago, sa2000 said:

It is per .db file and each .db file can multiple connections up to a set maximum

We have these databases: authentication.db, activitylog.db, users.db and library.db.

The cache is defaulted as 128Mb per connection for the library.db and hard wired at 64Mb for each if the connections to the other db's

We can have up to 5 connections for each of the library.db and authnetication.db and up to 3 connections for each of the remaining 2 databases. So  with the defaults, the max cache Mb usage could be 640Mb for the library.db and 704Mb for the other 3 db files.

 

So maximum 

Thank you so much for your time and explanation; the information is very valuable for a better understanding of the cache flow. I will be monitoring and commenting further.
Best regards.

[gene0915 42]

Seeing something similar but I'm not using rclone. I'm using Altmount, with it's native Fuse mount setting. Server gets minimal usage but after 24+ hours, Emby was taking up 1.2 gigs of RAM. Running it on a bare metal Debian 13 install.

[sa2000 731]

16 hours ago, gene0915 said:

but after 24+ hours, Emby was taking up 1.2 gigs of RAM. Running it on a bare metal Debian 13 install.

That could be when the Scheduled Task "Scan media library" runs

[kikinjo 306]

Post your rclone config first

[gene0915 42]

8 hours ago, sa2000 said:

That could be when the Scheduled Task "Scan media library" runs

I'll check it again Sunday night because my server does daily reboots except on Sunday so there will be 48 hours worth of uptime to look at. Also, I don't think any library scans were happening but I'll double check that as well.

[gene0915 42]

6 hours ago, kikinjo said:

Post your rclone config first

My Altmount install doesn't use rclone. I'm using its' native Fuse mount option:

[sa2000 731]

currently there are two known problem areas that could lead to very high memory use.

1. Scheduled Periodic scans of large libraries

2. Windows tabbed Emby Web server dashboard session with client playbacks in progress and the recently introduced MS Edge suspension of inactive browser tabs (eg not in focus) - Investigation into this started with this forum post

[yocker 1518]

4 hours ago, sa2000 said:

currently there are two known problem areas that could lead to very high memory use.

1. Scheduled Periodic scans of large libraries

2. Windows tabbed Emby Web server dashboard session with client playbacks in progress and the recently introduced MS Edge suspension of inactive browser tabs (eg not in focus) - Investigation into this started with this forum post

My memory usage actually improves when starting a scheduled task to scan libraries.
Sometimes from 3GB+ down to 2GB

[sa2000 731]

8 hours ago, yocker said:

My memory usage actually improves when starting a scheduled task to scan libraries.
Sometimes from 3GB+ down to 2GB

interesting. 

For Scheduled Task for periodic scans of all libraries where the interval between scans is less than the time before clearing unused memory kicks in would lead to sustained high memory use at levels when scanning the very large libraries