DSM 7.3 system is out of memory

[sa2000 674]

10 hours ago, Kiniu said:

i just download all of them

Hmm..... we lost one log file - the one for period 2025-12-01 12:11 to to 23:59:59. Strange because we do have the log before it so it was not purged. Maybe you had it open when you zipped the files and the zipping would skip any open files 

At 23:59:59 memory was only at 1.3Gb so I do have logs for the climb from that level to 5.3Gb

 

[Kiniu 22]

sure thing this could happen. i zip it again and i added some logs that i downloaded earlier.

emby logs.zip

[Kiniu 22]

Hello SA2000.

it crashed again last night. sending all the logs....

emby logs06122025.zip

[sa2000 674]

On 04/12/2025 at 12:21, Kiniu said:

sure thing this could happen. i zip it again and i added some logs that i downloaded earlier.

 

2 hours ago, Kiniu said:

It crashed again last night. sending all the logs....

The crashes appear to relate to scanning.

I would like to suggest these changes - whilst we have issues with scanning of large libraries

Amend Scheduled Tasks for:

Scan Media Library - change it from every 12 hours to once every 7 days

Scan Metadata Folder - Delete the daily scheduled task and only run it manually if you make direct changes to the metadata folder

Fix your realtime libraries monitor for changes. You have reached the 8192 limit. With this fixed, changes should get detected automatically for all your media and there would be less of a need for scheduled library scans. 

System.IO.IOException: System.IO.IOException: The configured user limit (8192) on the number of inotify watches has been reached, or the operating system failed to allocate a required resource.

I did mention this to you on the 21 November. Did this not help you find how to fix it ?  How to fix RTM not working caused by limited inotify instances/watches

I am hoping with the changes to the scheduled tasks, that the emby server will last a week or more.

Once all the changes are made, start a new memory logging session and then restart the emby server and we see how long it takes before being OOM Killed by the OS

This version of the script is restartable - it would append to the existing file if restarted. Of course, best to just let it run and not do any restarts 

(echo "PID,time,VmPeak,VmSize,VmLck,VmPin,VmHWM,VmRSS,VmData,VmStk,VmExe,VmLib,VmPTE,VmSwap"; while :; do PID=$(pidof EmbyServer | awk '{print $1}'); [ -z "$PID" ] && { sleep 1; continue; }; printf "%s," "$PID"; date "+%F %T" | tr '\n' ','; awk '/^VmPeak|^VmSize|^VmLck|^VmPin|^VmHWM|^VmRSS|^VmData|^VmStk|^VmExe|^VmLib|^VmPTE|^VmSwap/ {gsub(/ kB/, "", $2); gsub(/[ \t]/, "", $2); printf "%s,", $2}' /proc/$PID/status | sed 's/,$//'; echo; sleep 1; done) | tee -a "$(cat /etc/hostname)_emby_memory_log_$(date +%F).csv"

and since I am expecting it to last more than 3 days before crashing and with the logs being purged after 3 days, could you every 2-3 days, save the embyserver-xxxx.txt files to accumulate them so we would have the whole set from launch when it does crash

Thanks

 

 

 

Edited December 6, 2025 by sa2000

[Kiniu 22]

Ok. i shall do that. let you know abut results.

I only want to mention that i do manually scan quite offen because i do changes in library regullary, and it never crashed while triggered manualy.Anyway i take your advise and do suggested changes. thank U.

[Kiniu 22]

Hi SA2000.

Seems like didn't crash soo far so maybe we live this like that but i would like to look for permanent solution eventually, for now is good, i will keep you posted if anything happen. thank u for you help and so much patience.

[Luke 42077]

17 hours ago, Kiniu said:

Hi SA2000.

Seems like didn't crash soo far so maybe we live this like that but i would like to look for permanent solution eventually, for now is good, i will keep you posted if anything happen. thank u for you help and so much patience.

 

Why did you give this a schedule in the first place?

Quote

Scan Metadata Folder - Delete the daily scheduled task and only run it manually if you make direct changes to the metadata folder

 

[Kiniu 22]

Hello Luke.
To be honest with you, I don’t remember setting up this. I’m pretty sure it was set up by default, but anyway, I use Emby for quite a long time now and this was never a problem only recently this became a problem, which is still becoming a mystery for me why it crashes when triggered by task scheduler and it’s not crashing when triggered manually. And that’s actually create another question.  How much memory by default Emby needs to work smoothly without interruptions (?) let’s say with five active clients apps?

 

[Luke 42077]

14 hours ago, Kiniu said:

Hello Luke.
To be honest with you, I don’t remember setting up this. I’m pretty sure it was set up by default, but anyway, I use Emby for quite a long time now and this was never a problem only recently this became a problem, which is still becoming a mystery for me why it crashes when triggered by task scheduler and it’s not crashing when triggered manually.

 

It is probably the cumulative affect of it running multiple times. Ideally we wouldn't even let you setup a schedule for this in the first place, but we need a place for tasks that allows you to start, stop and monitor progress, and currently scheduled tasks is the only mechanism we have for that.

[dao2009 2]

Ok, I've had this problem on Synology (7.2) where my emby server is suddenly using all of my memory. I have 8Gb installed on a 1019+ system, emby server using 6Gb making system completely unresponsive.
Interestingly, I have 2 other servers running - one on a debian minimal install with all the same scheduling (mine was also scanning every 12 hours). That is running at around 1.5Gb (from 32Gb installed on ryzen 7 5825U processor). This server only has 3 libraries as opposed to the 7 I have on the Synology - same libraries just use as a backup for emby server on Synology.
The 3rd server I am experimenting with is a new unraid server running on a ugreen nas (12th Gen Intel® Core™ i5-1235U, 32Gb ram - I'm thinking or replacing the debian one). It has same 3 libraries as my debian instance - and that is running at 6Gb memory using all the same settings - scanning etc...
All 3 servers are running the latest 4.9.1.90 emby server version with debian running from a straight docker compose file, unraid running from their app install (also docker) and Synology running from the direct download from emby themselves.

I have always installed the latest stable release. This problem has only surfaced from the 4.9 install - I had no issues from the previous version and never had to restart the emby server to release the memory on Synology before. 

At the moment I did change the scanning settings to 1 per week on synology, twice per week on debian and left the unraid version untouched from default to see how things go though i think I might have to look at the unraid version if the memory keeps increasing. (the unraid server is only 3 weeks old at the moment which is why I'm just at the experimental stage of things) 

All media files are held on my Synology with mounted filesystems running on both debian and unraid. Playback from Synology has always been a bit sluggish compared to the other two systems but the Synology system is now 6 years old. If anyone is interested I can post an update as to how things are going in the coming weeks