Docker daemon eating up disk I/O

Currently reading
Docker daemon eating up disk I/O

777
291
NAS
DS216+II, DS118, DS718+, DS720+
Router
  1. RT2600ac
  2. MR2200ac
Operating system
  1. Windows
Mobile operating system
  1. Android
I'm asking this question on behalf of someone from another (Dutch) forum.

Anyone seen this before and have any idea what is causing this?

Kw7AqsFfdA2SCLn9lENCXGs0.jpg


User is only running this container, and this disk activity only seems to hapen when this container is started:
GitHub - qdm12/gluetun: VPN client in a thin Docker container for multiple VPN providers, written in Go, and using OpenVPN or Wireguard, DNS over TLS, with a few proxy servers built-in.

author if the image has no idea why this person is getting such high disk I/O when this container is started....

Original post..
 
disk activity + container is frequently integrated with a network traffic

this is my attitude to new container tests (when the person doesn't have Portainer):

Network traffic check

simple dashboard:
Bash:
docker stats
you can find there block I/O also

or directly with the container name:
Bash:
docker stats <name>

then more deeply and straight forward (get IP of the container)
Bash:
docker inspect --format='{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' $INSTANCE_ID
you need the $INSTANCE_ID from the container
or
Bash:
docker network ls
then
Bash:
docker network inspect <name> from the 'ls'
you will get IP address of the container

then check of the traffic (in these days most important (without your data, and after)
Bash:
tcpdump host <IP container address> -n -s 65535 -w /path to somewhere/wireshark-log.pcap
analyze the traffic

then find the traffic and exact process ID:
Bash:
netstat -tunp | grep <port_number>

for "unexpected" events you can use:
Bash:
docker events --since <'x'> --filter 'container=<name>' --format 'Type={{.Type}}  Status={{.Status}}  ID={{.ID}}'
where the <'x'> is:
- value in minutes, then use '5m'
- value in date, then use '2021-12-20'
- or a combination of them e.g. '2021-12-20T15:45:00'
and many other combinations
 
Upvote 0
Last edited:
@Shadow

Thanks for the reference to this forum, and for opening the topic with my problem.
I thought it would be useful to comment here as well.

In the topic start, the problem has already been explained well. But to put it briefly again.

- DSM7 docker --> gleutun container
- wireguard in kernel or userspace

Start container and directly everey few seconds 300/400 kbs R/W IO

Together with @Shadow I found out that this is caused by the dockerD.

@jeyare Thanks a lot for your input. Although I am not new to linux and cli commands, I am not an advanced user either. But - docker stats - gave me some usefull info.

I can see the container show up at start.
And I immediately see the live stats of the suggested network traffic. I see there the initial start of the wiresguard client. It grabs some data through the tunnel, and then the traffic comes to a standstill.

When I open websites via the http proxy I see the Net IO rise. Then nothing again.
The block IO remains at zero. So, i can conclude that there is no hard drive activity at all ?
Sorry, the rest of your suggested commands are a little to advanced for me.

Code:
CONTAINER ID   NAME        CPU %     MEM USAGE / LIMIT     MEM %     NET I/O           BLOCK I/O   PIDS
daed89fef666   gluetun     0.00%     339.2MiB / 3.678GiB   9.01%     7.97MB / 2.58MB   0B / 0B     0

So, this morning i deployed a new container with minimal arguments in portainer.
This gave me the same effect. Just to be sure, i stopped every other service. And
anything else that could cause HDD I/O.

Stopping the container, and the drives goes silent. Any other container does not give this effect.

Any input is welcome, and thanks a lot!
 
Upvote 0
First:
Bash:
grype qmcgaw/gluetun:latest
✔ Vulnerability DB [no update available]
✔ Parsed image
✔ Cataloged packages [64 packages]
✔ Scanned image [0 vulnerabilities]
No vulnerabilities found

Second:
I'm trying to replicate the problem in my test lab, so far nothing serious
nothing suspicious there

need time to understand the logic of internal container services (responsible for the iops)
 
Upvote 0
I'm hoping to also get the view of @one-eyed-king 's expertise...
I must admit, I have no theory so far, just a hunch.

Just thinking, could this issue only occur on Synology NAS'es? I know that would be absolutely against what Docker was originally designed for..
Synology's docker is not a vanila docker. The proprietary Synology log driver is not part of the docker eco system. The log driver might be a candidate if the container itself writes plenty of logs (to the console or into the filesystem)- or if it includes a forward proxy (squid?) that caches artifacts in the container's filesystem.

N.B.: My experience is that vanila docker behavior can only be expected from a vanila docker engine (=from docker's own apt/rpm repositories). Even though forks shared the same code base at one point, doesn't necessarily mean they behave like "the original" until infity... For instance the snap docker package is so mutilated that I don't even consider it as docker.
 
Upvote 0
Oke guys. I've not found a reason or a solution. But the IO rumble on the drives
irritated me a lot. So, i made a dirty workaround.

Migrated the docker package and the container to a 2Tb Nvme. Noise is gone, IO is still there.

Hopefully one day i will find out what i did wrong. Or, what is going on with Gluetun giving me extra IO.

Thanks for now.
 
Upvote 0

Create an account or login to comment

You must be a member in order to leave a comment

Create account

Create an account on our community. It's easy!

Log in

Already have an account? Log in here.

Similar threads

For the heck of it, I just checked again in docker container, and it announced an update was available. I...
Replies
4
Views
665
  • Question
Do realize, that enabling any user to run docker containers is largely the same as giving that user full...
Replies
6
Views
1,267
Hello, I already have it configured perfectly with wireguard. I was looking at the Gluetun configuration...
Replies
4
Views
940
Thanks... I tried something similar with rsync. The docker volume lived in...
Replies
7
Views
960
I can’t find any option to restore just the settings. 1710356648 Phew, managed to fix it. Within the...
Replies
4
Views
732
Good to hear. Deluge has not been updated for almost two years now as an app, nevertheless. But it gives...
Replies
12
Views
1,430

Welcome to SynoForum.com!

SynoForum.com is an unofficial Synology forum for NAS owners and enthusiasts.

Registration is free, easy and fast!

Back
Top