High I/O makes container restart

[gdlk]

I am using the Docker version of FileBot on my Synology DS218+. Regardless of whether it's the XPRA or VNC GUI version, it frequently causes excessive I/O usage when processing files. Checking with uptime command in the Synology command line shows that the I/O load can exceed 100. At this point, the container usually becomes unresponsive, and the system automatically restarts it. I’m not sure what is causing this issue.

The uptime output is like this, the value may increase to 100+ sometimes.

Console Output: Select all

# uptime
 15:50:22 up 117 days,  2:07,  5 users,  load average: 40.54, 27.16, 21.12 [IO: 40.18, 26.09, 19.45 CPU: 0.36, 1.06, 1.65]

This the I/O usage screenshot.

[rednoah]

excessive I/O usage

What is the I/O doing?

At random unrelated to what you do? What process inside the container is doing the I/O operations? Where is it doing the I/O operations? What is it reading / writing?

In response to you moving files? Are you using atomic move operations or copy+delete operations to move files? (see Notes on Docker Bind Mounts)

How does I/O make a container restart? Did you set some hypervisor limits of some kind? I've only ever heard of memory limits where processes are killed suddenly if the memory usage is too high.

[gdlk]

The system usually freezes when FileBot is matching metadata or loading filters (in the GUI). However, I later discovered through iotop that the package version of Emby was also performing a large amount of I/O operations at the same time. I suspect this is because I had added a large amount of data using FileBot, causing Emby to frequently scan the files. When FileBot performs its own I/O operations concurrently, the system freezes. After I stopped Emby and ran FileBot again, the issue no longer occurred.