Slow writing to array

[lotekjunky]

I've been troubleshooting an issue, but I think it's time I go back to basics. My issue is that when copying from my NVME cache drive to my 4x8tb=1 array, the copy will inevitably drop to a crawl. It will move data successfully at first, but at some point, relatively quickly, it will slow down to 700k or worse. I figured that maybe I had an issue with one of the drives in my array. Some are several years old, and I was just going to swap in a new 8TB Red.  I can't figure out which disk it is, and now I'm wondering if that was even the problem to begin with.

 

When I ssh in, i use mc to copy stuff. this example is from /mnt/cache to /mnt/user0/tv.  Copying to this path will slow to a crawl.  I tried copying directly to /mnt/disk1/tv, disk2, etcc... all of them were fine. I couldn't get it to slow down at all. Then I used the diskspeed docker app and found that after 5 increasingly thorough tests, all of the drives pretty much perform exactly the same.

 

What am I missing? What would I need to provide to help with troubleshooting?

 

Thanks!

Nick

 

Epilogue: I don't know that this has ever worked on this server. I know I had slowness issues on my old server, but it was VERY old and only had a few cores running LUKS encryption. All of that was just too much for that thing and I built a brand new 8 core server in April.  When I was loading data back onto the array from my archive backup, it was SO SLOW. I thought my archives were going bad, but I got super busy at work and now here I am. I went down this road last week because I thought "hey, one of these drives is slow and it's breaking my tv cache." Now i'm wanting to look at it more holistically.

[lotekjunky]

Would this better fit in another section? Where do pro license holders obtain support?

[trurl]

On 10/27/2021 at 12:25 PM, lotekjunky said:

What would I need to provide to help with troubleshooting?

attach diagnostics to your NEXT post in this thread.

 

16 minutes ago, lotekjunky said:

Where do pro license holders obtain support?

Free support for all users regardless of license is on the forum, mostly from your fellow Unraid users. If you want to negotiate paid support use the Contact link.

[lotekjunky]

20 hours ago, trurl said:

attach diagnostics to your NEXT post in this thread.

 

Free support for all users regardless of license is on the forum, mostly from your fellow Unraid users. If you want to negotiate paid support use the Contact link.

 

Thanks for your response. I wasn't sure if I was in the right area, or if there was a support section for pro and I just wasn't added to it. No biggie, thanks for the clarification.  I've attached my diagnostics report.  I really appreciate your help, I'm at my wits end.

vein-diagnostics-20211029-0822.zip

[JorgeB]

Try excluding disk1 from the share you're copying to and see if there's any difference, disk1 is SMR and with some workloads it can slow down things by a lot.

[lotekjunky]

On 10/29/2021 at 8:54 AM, JorgeB said:

Try excluding disk1 from the share you're copying to and see if there's any difference, disk1 is SMR and with some workloads it can slow down things by a lot.

WOW< I didn't even know that disk was SMR.  How could you tell? I never even thought of that... With that in mind, and the fact that I have another 8TB drive here to replace it... could I just yeet that drive and run it emulated to see if it works any better? (I'm not sure how writing to an array with an emulated disk works... better or worse in my case).

[trurl]

7 minutes ago, lotekjunky said:

How could you tell?

SMART report in diagnostics for disk1

Model Family:     Seagate BarraCuda 3.5 (SMR)

 

8 minutes ago, lotekjunky said:

writing to an array with an emulated disk works

Parity and all other disks are read to calculate the data for the missing disk. That is the same whether reading or writing.

 

Change to parity for the write is determined and parity is updated accordingly.

 

So, the data for that emulated write can be read again.

 

Parity and all other disks are read to calculate the data for the missing disk.

 

Etc.

[lotekjunky]

so theoretically, running on emulated disk should be as fast as normal because it's either calculating the parity bit for the parity drive, or reverse for the emulated drive. if that's not right, just tell me, you don't have to explain it in great detail, i'm just trying to grasp the basics at this point.  I'm gonna yank that drive tomorrow (or soon) and test it out anyhow. I was originally just going to exclude disk1 from the share, but it's so slow it can't even mover it off of there, and it was running poorly all around, so that's what brought me to here. Thanks for the info, I'll leave an update as time allows. Life, ug. Thanks.