Jump to content
jbuszkie

How slow is dual parity?

19 posts in this topic Last Reply

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

Share this post


Link to post
3 minutes ago, jbuszkie said:

No this is a modern 4 core.. (8 thread) i7..

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.

Share this post


Link to post
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

Share this post


Link to post

also what parity write strategy are you using? RMW or Turbo Write? the former would definitely be ugly.

Share this post


Link to post
1 minute ago, sota said:

also what parity write strategy are you using? RMW or Turbo Write? the former would definitely be ugly.

My md_write_method is set to reconstruct write.

Share this post


Link to post

I think my issue might be the fact that my destination drive is an archive (Shingled?) drive?  That might be killing my writes? 

 

Jim

Share this post


Link to post
2 hours ago, jbuszkie said:

But I wonder if it's still trying to emulate the disk I upgraded...

If the rebuild completed then it is definitely not emulating the disk you upgraded (unless it became disabled since, of course). Not sure why you might think that.

Share this post


Link to post
53 minutes ago, trurl said:

Not sure why you might think that.

Grasping at straws?? 😄

 

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

Share this post


Link to post
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. 

Share this post


Link to post
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..  

Share this post


Link to post
Posted (edited)

I don't see anything in the syslog..

image.thumb.png.ac1c1a9350420c5d55c2fad294a5425c.png

 

Granted I  have a pre-clear running now..  But I was getting these numbers yesterday without the pre-clear..

 

Edit:  Pre-clear Pre-read @178MB/s right now...

 

tower-diagnostics-20200326-1619.zip

Edited by jbuszkie

Share this post


Link to post

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.

Share this post


Link to post
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..

Share this post


Link to post

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.

Share this post


Link to post
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....

 

Share this post


Link to post

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.