New unRAID Server - Plex Disks & Shares (from an idiot!)

[ceepeebee]

Hi all,

 

After a play around with unRAID on an old Microserver, I plumped for a proper build and have it in situ now. I created my shares, dumped some drives in, and started copying all my native data (docs, pics, etc) and Plex data to it as well as ensuring my dockers were up to date etc.

 

I sit here now, proud that almost all of my 12TB of media has transferred over; I then suddenly realise that as I'll be running file sharing, some other media servers and more, all from the same "array", I might suffer something I hadn't previously thought of as I had a dedicated PMS before; performance issues.

 

So, whilst my media is now scattered across all disks, I'm aware that, had I not been a complete fool, I might have been able to think about this a bit more without battering my disks.

 

My question is, am I worrying about nothing? I have a combination of 5900 and 7200RPM drives in the array (7200 parity drive). Am I likely to actually see performance stutters and bottlenecks from general file shares and backups etc. My guess is "very possibly".

 

Share with me your setups if you think it will help as a teachable moment

[caplam]

it all depends of the load. Nobody can answer your question.

It's not the size of your library that matters but the number of clients across your various dockers and/or vm, the need of i/o, disk troughput,...

 

 

[Frank1940]

The only time I have noticed a performance hit is when doing a parity based operation (checking rebuilding, etc.).   Even then it was only noticeable in playing back BluRay content.  I have installed the 'Parity Check Tuning' plugin to breakup those type of operations to hours when normal user operations are not excepted. 

 

I do  have a cache disk to handle uploads of new material to the array and the mover is set to run at off hours also. 

 

If you think about it, scattering media content across multiple disks may actually help alleviate problems as disk head movement for any single drive will be reduced if that single disk is not trying to stream multiple streams to different clients.  In the distant past, I did test streaming two BluRay streams at the same time from a single disk without any issues.  Beyond two streams, I have no experience.

[ceepeebee]

Thanks to both for the replies.

 

Appreciate that there is no "golden rule" here and throughput, additional services, data location will all play a part.

 

@Frank1940 - you said you use the Parity Check Tuning plugin to restrict the checks to certain times. Presumably that runs for a few hours overnight, pauses, continues, and so on and so on until it's complete? How big is your array and do you find this overlaps the parity check runs?

 

[Frank1940]

8 minutes ago, ceepeebee said:

ou said you use the Parity Check Tuning plugin to restrict the checks to certain times. Presumably that runs for a few hours overnight, pauses, continues, and so on and so on until it's complete? How big is your array and do you find this overlaps the parity check runs?

 

I use it on the Media Server which is 6TB 'tall'.  (Spec's for my two servers are in my signature.   IF you don't see signatures, click on your user-name in the header and go to account settings.

 

Here are the Parity Check Tuning settings that I use:

It takes two nights to complete the monthly parity check on this server.  The Testbed Server is only 3TB 'tall' so it runs in about eight hours which is not a problem for me. 

[ceepeebee]

So, furthermore @Frank1940 How does this interact with the standard parity checking time above that setting? I've just grabbed the plugin and I've set my schedule to monthly, to begin on the 1st of each month at 1.30am. I've then setup the tuning settings to 1.30am and 4.30am daily to allow a few hours each day for the check.

 

The reason I've made the window so small is the mover task runs daily at 4.40am. Can you confirm whether you take this into account too?

[Frank1940]

I have my mover task setup to run daily at 3:00AM.  BUT it does not always have something to move.  I don't know if I have ever had both the parity check and mover running at the same time.  But I would suspect that it would impact the completion time of both.  Most of the time I would think that my mover task take from ten minutes to an hour-and-half.  I would suspect that if both were running it would double the time of both during the period of the mover operation.  But unless your delayed mover tasks take you into the active daytime usage period, what is the problem?  Both are background operations which should have no impact if it takes them a bit longer than normal.  Especially, the parity check.  Since one can set the Parity Check Tuning to run outside of normal usage hours, it makes no difference if the check is a hour or two longer in total duration.   (If the parity check is not paused during the usage hours, then a longer total elapsed time is a BIG Deal!)  So my advice would be run the parity check during the total available out-of-usage hours and let it end when it will.  One problem is that as the array becomes 'taller', the parity check time will be be over twenty four hours and , at three hours per night, it will take eight days plus to complete the check.  (This is a problem which many folks have not considered when looking at drives with very large capacities!  Think 16TB's...)

[ceepeebee]

Interesting - thanks for the response.

 

I have a 16TB parity drive, but the data array is actually utilising much smaller drives (for now...). So, I'll do as you suggested and see if I get any weird overlaps that cause me to take note.

 

Thanks again!

[itimpi]

1 hour ago, ceepeebee said:

furthermore @Frank1940 How does this interact with the standard parity checking time above that setting?

The plug-in never initiates the Parity Checks - it merely applies the pause/resume criteria you have set once a run has been started.   As such the standard Parity Checks still get initiated as expected from the standard settings.

[Frank1940]

1 hour ago, ceepeebee said:

I have a 16TB parity drive, but the data array is actually utilising much smaller drives (for now...).

 

The parity check will then be run across the entire 16TB since all drives (Including the parity drive) are checked to make sure that they are readable during any parity check.  So your time will be about 24 hours...