May 16, 20197 yr 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, 20196 yr by iilied
May 16, 20197 yr Community Expert (you should always) Go to Tools - Diagnostics and attach the complete diagnostics zip file to your next post.
May 16, 20197 yr Author 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
May 16, 20197 yr Community Expert 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.
May 16, 20197 yr Author 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?
May 16, 20197 yr 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, 20197 yr by HAMANY
May 16, 20197 yr 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.
May 16, 20197 yr Community Expert 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.
June 20, 20197 yr Author 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
Archived
This topic is now archived and is closed to further replies.