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

[jordan888 5]

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 1315]

@sa2000

[Luke 42077]

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

[sa2000 674]

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 5]

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 5]

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 674]

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 5]

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.