How slow is dual parity?


Recommended Posts

I just added a second parity disk.  That went fine.  Now I'm trying to empty a disk (using unbalance) so I can finally change the few riserfs's I have left.

Before dual parity, the move was about 30-45MB/s...  Now with dual parity I'm hovering  13-15MB/s

 

Is this expected?

 

Thanks,

 

Jim

Link to comment
1 minute ago, johnnie.black said:

Then dual parity isn't the reason for the slower performance, assuming the parity2 disk is working correctly, most likely it's copying small files or from a slower disk region.

No...  These are DVD VOB's  pretty decent size..

I just upgraded a disk.  It finished before I started the move..  Everything is green..   But I wonder if it's still trying to emulate the disk I upgraded...

Maybe I'll try a reboot.

Also, I started a docker upgrade (just recently after I noticed the slow move) and it's taking forever!  The dash board said I'm about 50-80% cpu usage...

Extracting is taking forever...

 

Once that's done I'll try a reboot, I guess...

 

Jim

Link to comment
56 minutes ago, jbuszkie said:

Grasping at straws?? 😄

 

I think the shingled drive might be my answer...

Is it slow during the entire transfer or starts fast and gradually/suddenly slows down?

 

Its my understanding that SMR drives leverage a CMR cache area to speed up writes but once it fills then any other writes slows to a crawl. 

Link to comment
50 minutes ago, civic95man said:

Is it slow during the entire transfer or starts fast and gradually/suddenly slows down?

 

Its my understanding that SMR drives leverage a CMR cache area to speed up writes but once it fills then any other writes slows to a crawl. 

 

I'm copying big enough files that get past the cache pretty quick, I imagine..   one thing I noticed when I broke the unbalance into smaller chunks, was that the copy would be "finished" but the remove (rm) command took a while.... or  like it was waiting for the disk to be ready again before it could start the next group..  

Link to comment

Not related but why do you have docker image on disk2 instead of cache?

 

Moves between disks in the array such as you are doing with Unbalance may be slower than just writing since it actually has to delete from the source after copying to destination. Also, looks like Mover was running so that might be competing for the disks. How often do you have Mover scheduled? Mover is really intended for idle time.

Link to comment
Quote

Not related but why do you have docker image on disk2 instead of cache?

I'm not sure..  It's what I did a while ago..  Maybe because I want it protected?  Maybe because my Cache is only 250GB?

 

Quote

How often do you have Mover scheduled?

It looks like every 4 hours..  Most of the time it doesn't run long.  Crash plan runs at idle time (overnight)..  And it seems to take a while to scan everything..

Link to comment

You want your docker image on cache so your dockers won't have their performance impacted by the slower parity writes and so they won't keep array disks spinning. There is no reason to protect docker image because it is easily recreated, and it isn't very large so there is no good reason to not have it on cache and plenty of reason to have it on cache.

 

Does Mover really need to run that often? It really is best if you have it run at idle time, so it isn't competing for the disks. And, there is no way to move from cache to the slower array as fast as you can write to cache, so if you are writing so much to cache that you think you need to run it that often, maybe you should reconsider how you use cache.

 

There is no requirement to cache writes to user shares. Most of my writes are scheduled backups and queued downloads. I don't care if they are a little slower since I'm not waiting on them anyway. So, those are not cached. Instead, they go directly to the array where they are already protected.

 

I mostly use cache for my appdata and docker image so my dockers perform better and don't spin the disks, as noted. I also use cache for my plex DVR since there is some benefit to the SSD speed when trying to record and playback at the same time. My normal user share writes are not cached.

Link to comment
Quote

You want your docker image on cache so your dockers won't have their performance impacted by the slower parity writes and so they won't keep array disks spinning. There is no reason to protect docker image because it is easily recreated, and it isn't very large so there is no good reason to not have it on cache and plenty of reason to have it on cache.

I guess when I first started using dockers I might not have understood completely how they worked.  I also may not have had an SSD cache drive back then?

It make sense to move it to the SSD..  

Quote

There is no requirement to cache writes to user shares. Most of my writes are scheduled backups and queued downloads. I don't care if they are a little slower since I'm not waiting on them anyway. So, those are not cached. Instead, they go directly to the array where they are already protected.

I'll have to go back and see..  My guess is some of my shares can go directly to the array..

 

My DVR stuff and code/work stuff will stay on the cache/array method though...

 

I can probably change the mover to once a day...  The SSD reliability is good enough that I don't have to be paranoid anymore.  I do plan on upgrading to two 500GB NVME cards so  I can have them in duplicate mode....

 

Link to comment
  • 1 year later...

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.