iilied Posted May 16, 2019 Share Posted May 16, 2019 (edited) there has been a constant issue i'm facing in the past few weeks with cpu spikes accompanied by reads/writes caused whenever a docker container is launched and running regardless of the app. even when the system is idle and not in use or connected to, the issue is still present. when all apps are stopped the issue disappears, and prior to installing pi-hole, this issue never existed. note, this is before and also after 6.7.0. htop / top / open files / plugins not sure how to go about this to identify the source of the problem. any help would be very much appreciated. cheers. note: posted on reddit too Edited August 15, 2019 by iilied Quote Link to comment
trurl Posted May 16, 2019 Share Posted May 16, 2019 (you should always) Go to Tools - Diagnostics and attach the complete diagnostics zip file to your next post. Quote Link to comment
iilied Posted May 16, 2019 Author Share Posted May 16, 2019 3 hours ago, trurl said: (you should always) Go to Tools - Diagnostics and attach the complete diagnostics zip file to your next post. apologies. attached are two diagnostics zip files; one with apps running and the other apps are off. [off]-tower-diagnostics-20190516-1457.zip [on]-tower-diagnostics-20190516-1509.zip Quote Link to comment
trurl Posted May 16, 2019 Share Posted May 16, 2019 You have no disks not in the parity array, so all dockers, etc. must use the parity array for all file activity, including working files, the docker service itself, etc. So, any writes are only going to be at the slower write speed required by parity updates, and parity and the involved data disk will be kept spinning. The usual best practice is to install cache (often SSDs are used for this) and have your appdata, domains, and system shares reside solely on cache. Your appdata share, where docker applications are typically configured for their working storage, is on disks 1,4. Your system share, where the docker image is configured to be, and where all dockers have their executables, is on disk1. Quote Link to comment
iilied Posted May 16, 2019 Author Share Posted May 16, 2019 2 hours ago, trurl said: You have no disks not in the parity array, so all dockers, etc. must use the parity array for all file activity, including working files, the docker service itself, etc. So, any writes are only going to be at the slower write speed required by parity updates, and parity and the involved data disk will be kept spinning. The usual best practice is to install cache (often SSDs are used for this) and have your appdata, domains, and system shares reside solely on cache. Your appdata share, where docker applications are typically configured for their working storage, is on disks 1,4. Your system share, where the docker image is configured to be, and where all dockers have their executables, is on disk1. alright, so this is what's causing cpu spikes? assuming i've installed a cache ssd (128gb), how would i go about moving appdata, domains, and system shares to it? Quote Link to comment
HAMANY Posted May 16, 2019 Share Posted May 16, 2019 (edited) 28 minutes ago, iilied said: alright, so this is what's causing cpu spikes? assuming i've installed a cache ssd (128gb), how would i go about moving appdata, domains, and system shares to it? After installing the cache drive, go to Shares and change the Use cache disk to Prefer to these shares: appdata, domains, system, and any other share you want. I think you have to run the Mover to take action. Edited May 16, 2019 by HAMANY Quote Link to comment
JonathanM Posted May 16, 2019 Share Posted May 16, 2019 In order for the mover to be able to work on a file, it must not be open. So, make sure the VM and docker SERVICES are disabled before you try to run the mover to accomplish the system file moves. The way you can tell you did it correctly is the lack of Docker and VMS menu items on the main GUI. Merely stopping all dockers and VM's is NOT enough, you must temporarily disable the services while the mover works. Quote Link to comment
trurl Posted May 16, 2019 Share Posted May 16, 2019 24 minutes ago, HAMANY said: go to Shares and change the Use cache disk to Prefer to these shares: appdata, domains, system, and any other share you want. Those shares are already cache-prefer according to his diagnostics. He just doesn't have cache for them. DO NOT set any other shares to cache-prefer. If you are only going to have 128G for cache, I recommend not setting any shares to cache-yes either. Quote Link to comment
iilied Posted May 18, 2019 Author Share Posted May 18, 2019 great, will do that and report back. thank you all. cheers Quote Link to comment
iilied Posted June 20, 2019 Author Share Posted June 20, 2019 update: ssd cache drive was installed, docker and all moved to cache, issue was monitored, and all is resolved by now. cheers to everyone… appreciative of the help 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.