SPOautos Posted March 26, 2021 Share Posted March 26, 2021 (edited) I have 32GB of ram and on the dashboard it showed 77% under docker and my server started running slow. I turned off the docker, its ram utilization max was set up 20GB and I changed it to 25GB and reenabled it. Now the server is running fine and its showing 55% usage for docker. HOWEVER when I look in the docker tab in advanced mode and add up all of the apps usage its only around 1.5-2 GB so I'm barely using any of my ram. I do not have a VM. What could be causing this problem? I attached a diagnostics log.... Also, I'm running 6.9.1 tower-diagnostics-20210325-2228.zip Edited March 26, 2021 by SPOautos Quote Link to comment
trurl Posted March 26, 2021 Share Posted March 26, 2021 28 minutes ago, SPOautos said: I have 32GB of ram and on the dashboard it showed 77% under docker The numbers on the Dashboard in the MEMORY section are not all RAM. The RAM indicator is showing how much of your RAM is used. The Flash indicator is showing how full your flash drive is. The Log indicator is showing how full the log space is. The Docker indicator is showing how much of docker.img is used. Now that I have cleared that up According to your diagnostics, Docker is currently disabled but is configured for 27G docker.img. 20G is usually more than enough. In my screenshot above, I am using 50% of 20G while running 17 containers. Making docker.img larger will not fix the problem of filling docker.img, it will only make it take longer to fill. The usual cause of filling docker.img is an application writing to a path that isn't mapped. Note that Linux is case-sensitive, so any path specified in an application must match a container path including upper/lower case. 1 Quote Link to comment
SPOautos Posted March 26, 2021 Author Share Posted March 26, 2021 (edited) 34 minutes ago, trurl said: The numbers on the Dashboard in the MEMORY section are not all RAM. The RAM indicator is showing how much of your RAM is used. The Flash indicator is showing how full your flash drive is. The Log indicator is showing how full the log space is. The Docker indicator is showing how much of docker.img is used. Now that I have cleared that up According to your diagnostics, Docker is currently disabled but is configured for 27G docker.img. 20G is usually more than enough. In my screenshot above, I am using 50% of 20G while running 17 containers. Making docker.img larger will not fix the problem of filling docker.img, it will only make it take longer to fill. The usual cause of filling docker.img is an application writing to a path that isn't mapped. Note that Linux is case-sensitive, so any path specified in an application must match a container path including upper/lower case. Is there a good way to see if that is happening? If I had this happening wouldnt I be downloading files that I then wouldnt be able to find? For instance if Radarr had a path that didnt match up with a share, where would the downloaded file go? Does it get stored in ram or something like that? 20GB should be plenty, I just increased it because the server was running slow....it got my speed back to normal. Hopefully I can get it fixed before it fills up again. Edited March 26, 2021 by SPOautos Quote Link to comment
lnxd Posted March 26, 2021 Share Posted March 26, 2021 2 hours ago, SPOautos said: For instance if Radarr had a path that didnt match up with a share, where would the downloaded file go? Does it get stored in ram or something like that? It'd be stored magically by Docker somewhere in /var/lib/docker, which is the mount point Unraid uses for docker.img. The next time the container gets updated it'll be deleted. Next time it happens, with Docker daemon started open a terminal window and run: docker ps --all --size It'll take a long time, but it'll spit out something like this (scroll all the way to the right in the following code block to see the sizes): CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES SIZE 9c50c41958a2 lnxd/xmrig "./init.sh" 2 hours ago Up 2 hours xmrig 3.06kB (virtual 15MB) 0a7f2f85a980 lnxd/phoenixstats "docker-php-entrypoi…" 4 hours ago Up 4 hours 0.0.0.0:5449->80/tcp PhoenixStats 1.67kB (virtual 415MB) 083266bebb23 lnxd/github-backup "./backup.sh" 7 hours ago Up 2 hours github-backup 202B (virtual 81.1MB) 8fb9e851dd0d lnxd/phoenixminer "./mine.sh" 7 hours ago Up 7 hours 0.0.0.0:5450->5450/tcp PhoenixMiner-AMD 6.48MB (virtual 1.61GB) You can then double check to see if you've configured the container correctly, and haven't missed a volume map. Quote Link to comment
SPOautos Posted March 26, 2021 Author Share Posted March 26, 2021 4 hours ago, lnxd said: It'd be stored magically by Docker somewhere in /var/lib/docker, which is the mount point Unraid uses for docker.img. The next time the container gets updated it'll be deleted. Next time it happens, with Docker daemon started open a terminal window and run: docker ps --all --size It'll take a long time, but it'll spit out something like this (scroll all the way to the right in the following code block to see the sizes): CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES SIZE 9c50c41958a2 lnxd/xmrig "./init.sh" 2 hours ago Up 2 hours xmrig 3.06kB (virtual 15MB) 0a7f2f85a980 lnxd/phoenixstats "docker-php-entrypoi…" 4 hours ago Up 4 hours 0.0.0.0:5449->80/tcp PhoenixStats 1.67kB (virtual 415MB) 083266bebb23 lnxd/github-backup "./backup.sh" 7 hours ago Up 2 hours github-backup 202B (virtual 81.1MB) 8fb9e851dd0d lnxd/phoenixminer "./mine.sh" 7 hours ago Up 7 hours 0.0.0.0:5450->5450/tcp PhoenixMiner-AMD 6.48MB (virtual 1.61GB) You can then double check to see if you've configured the container correctly, and haven't missed a volume map. Thanks! I'll run that next time it starts getting high. I suppose stopping docker and restarting it reset the issue, so I need to wait until it starts getting slow then run it at that time. 1 Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.