[Solved] [6.7.0] what's causing constant cpu spikes with read/write?

[iilied]

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

[trurl]

(you should always)

 

Go to Tools - Diagnostics and attach the complete diagnostics zip file to your next post.

[iilied]

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

[trurl]

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.

[iilied]

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?

 

[HAMANY]

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

[JonathanM]

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.

[trurl]

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.

[iilied]

great, will do that and report back. thank you all. cheers

[iilied]

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