Thunderbay 4 Finder Access Slow Even After DiskWarrior Rebuild and Reformat

@midihead7 
There are only two reasons for "slowness"
damaged directory
Drives spinning down, so are slow to spin up to access.

Do you have at least 15% free space on the volume?

Is this slowness only when "first accessing" in a while? Or always? If you set system to never sleep, etc, still happens?

I'm using Amphetamine to keep the drive awake every 10 seconds so I don't think that drive is spinning down and back up again that fast. Even with Amphetamine set to "Always Keep Drive Alive", it still happens. I have at least 15% free space on the drive. It responds much faster right after it has booted but the slowness gets worse within a few hours after booting the Mac. My system is already set to never sleep. I've run Disk Warrior several times recently, so I know the directory is OK. When I first boot the Mac, it responds reasonably quickly.

@midihead7 

Open Activity Monitor, CPU tab and sort by %CPU. Do you see anything using a lot of CPU?

Same with memory pressure.

Do you have any company installed anti malware, etc?

I don't have any company anti-malware software installed. Memory pressure is very low. I don't see anything using a lot of CPU under normal circumstances. Where I DO see high CPU usage is when I try to use the Open/Save dialogue when accessing my Thunderbay 4 a few hours after booting. See attached images. It happens whether Spotlight Indexing is enabled or disabled. Accessing the Thunderbay 4 outside of the Open/Save dialogue is fast otherwise.

@midihead7 

When you restart, all is good, but after a few hours, it pauses annoyingly when you go to open the volume?

A bit strange. Post a support file and I can look at your system, maybe see something...

Correct. I've also noticed that it affects the Finder outside of the Open/Save dialog but not quite as much as when using Open/Save. The support file is attached.

@midihead7 
I do not see anything obvious. Lets try something to try to rule out disks.

Note the disk#'s in SoftRAID disk tiles, in your support file they are disk4 disk5 disk6 disk7

These numbers change anytime you add disks, restart, etc, so confirm these are the disk numbers and change any if needed, below.

Paste this command into the terminal.app:
iostat -w 2 disk4 disk5 disk6 disk7

then launch SoftRAID, shift select the 4 drives and "verify disk" in disks column.

When the verify completes, use command . (cancel) to stop collecting data, then use command a command c (select all/copy) of the terminal window. Paste that data into a text edit file. Save it, use "Make plain text" and save again.
Paste it here. Lets see if any disks had issues. (pauses in particular)

Should I use the drive as normal during the verification or just let it run without disturbing the drive?

Attached is the iostat text file. The sections with no load at the beginning and near the end of the file are where the disk verification wasn't running. Thanks.

@midihead7 

THere were no significant disk pauses there.

Lets try one more similar test:
Go to the App store and get AJA System Test Lite.
Run AJA, set resolution to 8K video, Codec to 16bitRGBA, and file size to 64GB.
Select your volume to test.

Next, in settings, check "Dual DMA engine".
Check "Continuous"

Start the test, let it run for an hour, then stop it. (you can use the computer) CLick on System report in upper right.
It will show you all the runs you just performed. Copy that text into text edit, and post the same way.
when AJA ran, did you see any long dropouts? This will also test writes.

If nothing is wrong, then whatever is going on is with MacOS. You have proven it is not hardware.

Attached is the requested AJA System Test file.

@midihead7 

I am reviewing it, at first look it looked normal, but I need to set up similar disks, and see what I get, as there are some points where performance "minimums" drop a lot, I think that is normal, but need to test.

None of this suggests several second pauses, however.

Next thing would be to set up a second System macOS install, to prove it is something inside MacOS. I can send instructions for that. it will not affect your current system and will prove it is the drives, or the MacOS install.

Thanks. Please note that I wasn't using the drive for the entire hour but I did make a point to replicate the Finder slowness issue during the test.

Also, I'm wondering if my directory structures on my Thunderbay 4 are playing a role in the slowness. I do have two main folders, one for audio projects and the other for video projects. In each of these folders, I have at least 200 subfolders with many other subfolders nested inside of those to keep things organized. I did recently move at least half of the data to another backup drive and removed it from the Thunderbay 4, but this didn't seem to make a difference in the Finder slowness. I did, however, just try moving some recent projects into a few different parent folders outside of my main audio and video folders. When accessing those files with "Open/Save as" in the Finder, it doesn't seem to lag and feels normal speed-wise. It seems like the slowness may be specific to the original parent audio and video folders that have many nested subfolders even when my Mac has been on for more than 24 hours.

@midihead7 

COuld be. there was nothing showing drives misbehaving, that I could find. Certainly large folder structures can cause slowness.

Another thing to watch for is keep console. app open to the memory tab. Watch the bottom graph, "memory pressure" and see if that builds up over time.