unraid-tunables-tester.sh - A New Utility to Optimize unRAID md_* Tunables


Recommended Posts

After running the modified for 6.2 script and while a parity check is running I get the following status message:

 

unRAID Status: 21-09-2016 00:20

 

Notice [TOWER1] - array health report [FAIL]

Array has 24 disks (including parity & cache)

 

What can be wrong?

Should I be worried?

Is it related to 6.2, the utt script, the unthrottled valus I used or something entirely different?

Everything seems to be working as normal.

tower1-diagnostics-20160921-1043.zip

Link to comment

I have made a update to the GUI which allows real-time monitoring of disk read and write performance. For the moment it is just a test and available as a plugin, so it can be uninstalled easily.  ;)

 

I too have been enjoying this tool, has helped with some testing I've been doing.  Thanks!

 

We're getting off-topic though, perhaps it deserves its own thread?

 

Running the latest version - the Total column looks more like an average to me.  I would have expected a sum?

 

 

Is this plugin still around? The link doesn't work...

Link to comment

I have made a update to the GUI which allows real-time monitoring of disk read and write performance. For the moment it is just a test and available as a plugin, so it can be uninstalled easily.  ;)

 

I too have been enjoying this tool, has helped with some testing I've been doing.  Thanks!

 

We're getting off-topic though, perhaps it deserves its own thread?

 

Running the latest version - the Total column looks more like an average to me.  I would have expected a sum?

 

 

Is this plugin still around? The link doesn't work...

 

Squid updated it to 6.2 here

 

http://lime-technology.com/forum/index.php?topic=29009.msg492140#msg492140

Link to comment

Sorry for the slow reply, taken me some time to get round to running it! Here are the results from the short test, will run the longer one now.

 

--- INITIAL BASELINE TEST OF CURRENT VALUES (1 Sample Point @ 30sec Duration)---

 

Test | RAM | stripes | window | reqs | thresh |  MB/s

-------------------------------------------------------

  1  |  68 |  1280  |  384  | 128  |  192  | 107.6

 

--- FULLY AUTOMATIC nr_requests TEST 1 (4 Sample Points @ 60sec Duration)---

 

Test | num_stripes | sync_window | nr_requests | sync_thresh |  Speed

---------------------------------------------------------------------------

  1  |    1536    |    768    |    128    |      767    | 107.2 MB/s

  2  |    1536    |    768    |    128    |      384    | 104.5 MB/s

  3  |    1536    |    768    |      8    |      767    | 107.8 MB/s

  4  |    1536    |    768    |      8    |      384    | 107.3 MB/s

 

Fastest vals were nr_reqs=8 and sync_thresh=99% of sync_window at 107.8 MB/s

 

This nr_requests value will be used for the next test.

 

 

--- FULLY AUTOMATIC TEST PASS 1a (Rough - 4 Sample Points @ 30sec Duration)---

 

Test | RAM | stripes | window | reqs | thresh |  MB/s | thresh |  MB/s

------------------------------------------------------------------------

  1  |  40 |    768  |  384  |  8  |  383  |  95.3 |  192  | 100.0

  2  |  68 |  1280  |  640  |  8  |  639  |  94.8 |  320  |  94.4

  3  |  95 |  1792  |  896  |  8  |  895  |  94.8 |  448  |  91.0

  4  | 122 |  2304  |  1152  |  8  |  1151  |  90.9 |  576  |  90.8

 

--- FULLY AUTOMATIC TEST PASS 1b (Rough - 2 Sample Points @ 30sec Duration)---

 

Test | RAM | stripes | window | reqs | thresh |  MB/s | thresh |  MB/s

------------------------------------------------------------------------

  1  |  6 |    128  |    64  |  8  |    63  | 103.7 |    32  |  89.5

  2  |  34 |    640  |  320  |  8  |  319  | 105.3 |  160  |  99.0

 

--- END OF SHORT AUTO TEST FOR DETERMINING IF YOU SHOULD RUN THE NORMAL AUTO ---

Link to comment

I have made a update to the GUI which allows real-time monitoring of disk read and write performance. For the moment it is just a test and available as a plugin, so it can be uninstalled easily.  ;)

 

I too have been enjoying this tool, has helped with some testing I've been doing.  Thanks!

 

We're getting off-topic though, perhaps it deserves its own thread?

 

Running the latest version - the Total column looks more like an average to me.  I would have expected a sum?

 

 

Is this plugin still around? The link doesn't work...

 

Squid updated it to 6.2 here

 

http://lime-technology.com/forum/index.php?topic=29009.msg492140#msg492140

Nowhere near as thorough for 6.2 as what the next release by Pauven will do.
Link to comment

Sorry for breaking in, not my intention to hijack this thread, but I may have something of interest to you guys while you are running your performance tests.

 

I have made a update to the GUI which allows real-time monitoring of disk read and write performance. For the moment it is just a test and available as a plugin, so it can be uninstalled easily.  ;)

 

See the attached picture for the explanation.

 

At the top right a "button" is added which let the user toggle between read/write counters and read/write speed. Each disk is reported separately and when display refresh settings are set to "real-time" it will show the disk speeds in ... real-time.

 

Use the button to switch between views while at the main page.

 

I would be interested to know if the displayed speeds (they are taken from /proc/diskstats) correspond with your performance measurements. Or maybe the displayed speeds can help you in further tuning the tool.

 

The plugin can be installed by copy/paste URL: https://raw.githubusercontent.com/bergware/dynamix/master/unRAIDv6/dynamix.disk.io.plg in the plugin manager (requires unRAID 6.2rc4).

Will this work on a 6.1.9? or only on 6.2? If it only works for 6.2 and up (i.e. 6.1.9 users like me), should I run the .sh file from http://lime-technology.com/forum/index.php?topic=29009.msg492140#msg492140 instead?

Link to comment

Sorry for breaking in, not my intention to hijack this thread, but I may have something of interest to you guys while you are running your performance tests.

 

I have made a update to the GUI which allows real-time monitoring of disk read and write performance. For the moment it is just a test and available as a plugin, so it can be uninstalled easily.  ;)

 

See the attached picture for the explanation.

 

At the top right a "button" is added which let the user toggle between read/write counters and read/write speed. Each disk is reported separately and when display refresh settings are set to "real-time" it will show the disk speeds in ... real-time.

 

Use the button to switch between views while at the main page.

 

I would be interested to know if the displayed speeds (they are taken from /proc/diskstats) correspond with your performance measurements. Or maybe the displayed speeds can help you in further tuning the tool.

 

The plugin can be installed by copy/paste URL: https://raw.githubusercontent.com/bergware/dynamix/master/unRAIDv6/dynamix.disk.io.plg in the plugin manager (requires unRAID 6.2rc4).

Will this work on a 6.1.9? or only on 6.2? If it only works for 6.2 and up (i.e. 6.1.9 users like me), should I run the .sh file from http://lime-technology.com/forum/index.php?topic=29009.msg492140#msg492140 instead?

2 Different things.  The plugin has nothing to do with the tunables script.

 

The modified script in the link will work on 6.2 and 6.1.9

Link to comment
  • 2 weeks later...

Just thought I would report in.  My first monthly parity check ran with dual parity.

 

2016-10-04, 14:14:50	10 hr, 44 min, 49 sec	103.4 MB/s	OK

 

I'm pretty happy with the results.

 

Here are my current tunables:

 

Tunable (nr_requests):     8
Tunable (md_num_stripes):  2048
Tunable (md_sync_window):  1024
Tunable (md_sync_thresh):  994

Link to comment

Hi there

 

I tried to run the utility, but get the following error:

 

unRAID Tunables Tester v2.2 by Pauven

Please select what type of test you would like to perform:

     (V) Veryfast  - 4 Second Test Pass, produces inaccurate results
     (F) Fast      - 20 Second Test Pass, produces rough results
    *(N) Normal    - 2 Minute Test Pass, produces good results
     (T) Thorough  - 4 Minute Test Pass, produces great results
     (E) Extreme   - 10 Minute Test Pass, produces accurate results
     (FULLAUTO)    - Automatic test takes 2.1-2.3 Hours. Recommended.
     (C) Cancel

Enter V F N T E or FULLAUTO to continue or C to cancel:
FULLAUTO
unRAID Tunables Tester v2.2 by Pauven

                            FULLY AUTOMATIC TEST

This test runs 2 passes, starting with a Rough Pass that covers the full range
of assignable values in granular fashion to find what range suits your
hardware.  Then a Final Pass targets the fastest range in more detail and
hones in on the best values for your server.

                     THIS TEST WILL TAKE 2.1 TO 2.3 HOURS!

        FOR ACCURATE RESULTS, DO NOT ACCESS YOUR SERVER DURING THE TEST!

Are You Sure? (Y to continue):
Y
unRAID Tunables Tester v2.2 by Pauven

--- FULLY AUTOMATIC TEST PASS 1 (Rough - 20 Sample Points @ 3min Duration)---

/root/mdcmd: line 11: echo: write error: Invalid argument
Test 1   - md_sync_window=512  - Completed in 179.578 seconds = 108.9 MB/s
/root/mdcmd: line 11: echo: write error: Invalid argument
Test 2   - md_sync_window=640  - Completed in 179.529 seconds = 109.0 MB/s
/root/mdcmd: line 11: echo: write error: Invalid argument
Test 3   - md_sync_window=768  - Completed in 179.584 seconds = 109.0 MB/s
/root/mdcmd: line 11: echo: write error: Invalid argument
Test 4   - md_sync_window=896  - Completed in 179.575 seconds = 108.9 MB/s
/root/mdcmd: line 11: echo: write error: Invalid argument
Test 5   - md_sync_window=1024 - Completed in 179.564 seconds = 109.0 MB/s
/root/mdcmd: line 11: echo: write error: Invalid argument
Test 6   - md_sync_window=1152 - Completed in 179.588 seconds = 109.1 MB/s
/root/mdcmd: line 11: echo: write error: Invalid argument
Test 7   - md_sync_window=1280 - Completed in 179.572 seconds = 109.1 MB/s
/root/mdcmd: line 11: echo: write error: Invalid argument

 

Link to comment

I have made a update to the GUI which allows real-time monitoring of disk read and write performance. For the moment it is just a test and available as a plugin, so it can be uninstalled easily.  ;)

 

I too have been enjoying this tool, has helped with some testing I've been doing.  Thanks!

 

We're getting off-topic though, perhaps it deserves its own thread?

 

Running the latest version - the Total column looks more like an average to me.  I would have expected a sum?

 

 

Is this plugin still around? The link doesn't work...

 

Squid updated it to 6.2 here

 

http://lime-technology.com/forum/index.php?topic=29009.msg492140#msg492140

 

Ran the script from the above post, selected the 10 minute test, and the full iterations ran for 2 1/2 hours ... results were:

 

    Tunable (md_num_stripes): 1280

    Tunable (md_write_limit): 768

    Tunable (md_sync_window): 384

 

Basically what I had before, but for some reason "md_write_limit" was blank?  I don't have a screen shot, but that's what the tool reported.

 

Anyway, I guess my Cortex server has been running reasonably optimally all along.  Good to know, though...

 

Link to comment

 

Ran the script from the above post, selected the 10 minute test, and the full iterations ran for 2 1/2 hours ... results were:

 

    Tunable (md_num_stripes): 1280

    Tunable (md_write_limit): 768

    Tunable (md_sync_window): 384

 

Basically what I had before, but for some reason "md_write_limit" was blank?  I don't have a screen shot, but that's what the tool reported.

 

Anyway, I guess my Cortex server has been running reasonably optimally all along.  Good to know, though...

 

Squid updated it so it would run, with 6.2, but it's not actually valid for 6.2.  As of 6.2, md_write_limit is gone and md_sync_thresh has been added, with a default value of 192.  Your md_sync_window would be fine at 384, twice the value of md_sync_thresh, but would probably show worse performance with higher values of md_sync_window.  According to Tom, md_sync_thresh needs to be in the range of (md_sync_window/2) to (md_sync_window-1).

 

We're waiting for an updated tunables script.

Link to comment

 

Ran the script from the above post, selected the 10 minute test, and the full iterations ran for 2 1/2 hours ... results were:

 

    Tunable (md_num_stripes): 1280

    Tunable (md_write_limit): 768

    Tunable (md_sync_window): 384

 

Basically what I had before, but for some reason "md_write_limit" was blank?  I don't have a screen shot, but that's what the tool reported.

 

Anyway, I guess my Cortex server has been running reasonably optimally all along.  Good to know, though...

 

Squid updated it so it would run, with 6.2, but it's not actually valid for 6.2.  As of 6.2, md_write_limit is gone and md_sync_thresh has been added, with a default value of 192.  Your md_sync_window would be fine at 384, twice the value of md_sync_thresh, but would probably show worse performance with higher values of md_sync_window.  According to Tom, md_sync_thresh needs to be in the range of (md_sync_window/2) to (md_sync_window-1).

 

We're waiting for an updated tunables script.

 

Thanks RobJ ... was wondering what all the hub-bub was about waiting for a 6.2 script if we had one.  Guess we don't really...

 

I just looked in my disk.cfg file, and there is no entry for md_write_limit ... so I guess the setting added by the older script was removed by the system?  I'm not sure where else to look.

 

The rest of the md_* settings look like this:

 

    md_num_stripes="1280"

    md_sync_window="384"

    md_sync_thresh="192"

    md_write_method="auto"

 

The older tunables script reported 131.9 MB/s with these settings.  Does that look/sound decent?

 

Thanks!

Link to comment

I just looked in my disk.cfg file, and there is no entry for md_write_limit ... so I guess the setting added by the older script was removed by the system?  I'm not sure where else to look.

As I said, it's gone in 6.2, so no need to look for it.

 

The rest of the md_* settings look like this:

 

    md_num_stripes="1280"

    md_sync_window="384"

    md_sync_thresh="192"

    md_write_method="auto"

 

md_write_method is unrelated, not a 'tunable'.  There is a fourth tunable - nr_requests, which can make a difference, especially with some hardware.  According to earlier testing, reasonable values appear to be 128 or 8 (and possibly 16 or 32), depending on which controllers are present.

 

The older tunables script reported 131.9 MB/s with these settings.  Does that look/sound decent?

Well, it's much faster than mine, an older system.

 

We aren't going to know until we have a script designed for 6.2, and then we can all figure out what the best numbers look like, for various hardware.

Link to comment
  • 1 month later...

I run v2.2 of the tunable script on my server with unRAID 6.2 before I noticed all the work @pauven and team did in August/September timeframe.

 

any plans to release v4.0 of the script?

 

One suggestion for this project to hopefully lighten the load on @pauven is to put the project on GitHub or your favorite open SCM and we can all contribute to it. Thoughts?

 

 

Link to comment
  • 2 months later...

I fear something may have happened to him.  He hasn't been on the forums since January 27, his last post was September 7 of 2016, and it said "Probably next week" - after being asked about a time frame for releasing an update.

 

I suspect he wouldn't mind if someone had time to do a little revision of the current testing version, for unofficial release.  Use his last discussion for guidelines.

 

Does anyone know him, could check on him?

Link to comment

I thought I would just chip in by confirming that 6.3.0 Parity times are *exactly* the same as 6.2.x on the array in my sig. I know someone asked in the 6.3.0 thread if the times had changed as part of the version change.

 

On my system the parity check times are about 25 minutes longer with 6.3 than they were with 6.2.4 -- about a 6% increase.  Not a huge difference, but nevertheless frustrating.  This is on an older system (Pentium E6300), so I'm sure it's simply a function a higher CPU load.  Not surprising that the times aren't different on a more modern system with a far more capable CPU.

 

Link to comment
  • 4 weeks later...
On 2/7/2017 at 1:16 PM, garycase said:

 

On my system the parity check times are about 25 minutes longer with 6.3 than they were with 6.2.4 -- about a 6% increase.  Not a huge difference, but nevertheless frustrating.  This is on an older system (Pentium E6300), so I'm sure it's simply a function a higher CPU load.  Not surprising that the times aren't different on a more modern system with a far more capable CPU.

 

 

How's the parity check times on 6.3.2?

Link to comment
On 2/7/2017 at 0:16 PM, garycase said:

 

On my system the parity check times are about 25 minutes longer with 6.3 than they were with 6.2.4 -- about a 6% increase.  Not a huge difference, but nevertheless frustrating.  This is on an older system (Pentium E6300), so I'm sure it's simply a function a higher CPU load.  Not surprising that the times aren't different on a more modern system with a far more capable CPU.

 

 

I have dual Xeons, and my parity check/build times are slower.  Its even more noticeable now that I'm migrating to 8TB drives.

Link to comment

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.