Jump to content
  • [6.7.x] Very slow array concurrent performance


    johnnie.black
    • Solved Urgent

    Since I can remember Unraid has never been great at simultaneous array disk performance, but it was pretty acceptable, since v6.7 there have been various users complaining for example of very poor performance when running the mover and trying to stream a movie.

     

    I noticed this myself yesterday when I couldn't even start watching an SD video using Kodi just because there were writes going on to a different array disk, and this server doesn't even have a parity drive, so did a quick test on my test server and the problem is easily reproducible and started with the first v6.7 release candidate, rc1.

     

    How to reproduce:

     

    -Server just needs 2 assigned array data devices (no parity needed, but same happens with parity) and one cache device, no encryption, all devices are btrfs formatted

    -Used cp to copy a few video files from cache to disk2

    -While cp is going on tried to stream a movie from disk1, took a long time to start and would keep stalling/buffering

     

    Tried to copy one file from disk1 (still while cp is going one on disk2), with V6.6.7:

     

    2083897607_Screenshot2019-08-0511_58_06.png.520373133cc121c80a361538a5fcc99b.png

     

    with v6.7rc1:

     

    856181720_Screenshot2019-08-0511_54_15.png.310bce8dbd6ed80d11d97727de55ac14.png

     

    A few times transfer will go higher for a couple of seconds but most times it's at a few KB/s or completely stalled.

     

    Also tried with all unencrypted xfs formatted devices and it was the same:

     

    1954593604_Screenshot2019-08-0512_21_37.png.6fb39b088e6cc77d99e45b37ea3184d8.png

     

    Server where problem was detected and test server have no hardware in common, one is based on X11 Supermicro board, test server is X9 series, server using HDDs, test server using SSDs so very unlikely to be hardware related.

    • Like 1


    User Feedback

    Recommended Comments



    1 hour ago, Carlos Talbot said:

    I'm just surprised this issue is still ongoing

    It isn't ongoing, it is an issue in the current stable, fixed in release candidate. Upgrade to release candidate or wait on the next stable.

    Share this comment


    Link to comment
    Share on other sites

    As I stated in my original post I'm on 6.8.0-rc7. With regards to my particular issue (cache pool/high load) it was reported in 2017 so over 2 years now.

     

     

    Share this comment


    Link to comment
    Share on other sites

    So Single BTRFS cache drive doesn't resolve the issue. What's the easiest way to reformat the drive to XFS? Thanks.

     

     

    Share this comment


    Link to comment
    Share on other sites
    3 hours ago, Carlos Talbot said:

    What's the easiest way to reformat the drive to XFS?

    Make sure that when the array is stopped, only 1 cache slot is shown. Then you can select XFS as the desired format type on the cache drive properties page, and when you start the array you should be presented with the cache drive as unmountable, and the option to format. Be sure the ONLY drive listed as unmountable is the cache drive, as the format option operates on all unmountable drives simultaneously.

    Share this comment


    Link to comment
    Share on other sites

    Thanks. I'm back to XFS and things are noticeably different. I tried the same copy process to a share that has cache enabled and load looked fine. I will avoid BTRFS until I hear otherwise.

    Share this comment


    Link to comment
    Share on other sites
    9 hours ago, Carlos Talbot said:

    As I stated in my original post I'm on 6.8.0-rc7. With regards to my particular issue (cache pool/high load) it was reported in 2017 so over 2 years now.

    The problem with this issue is that it only affects a small number of users, I for example can't reproduce it.

    Share this comment


    Link to comment
    Share on other sites
    6 hours ago, Carlos Talbot said:

    Thanks. I'm back to XFS and things are noticeably different. I tried the same copy process to a share that has cache enabled and load looked fine. I will avoid BTRFS until I hear otherwise.

    If you have the chance please try again btrfs but with COW/checksums disabled, you can do that by creating a new test share, set to use cache and with "enable copy-on-write" set to no.

    Share this comment


    Link to comment
    Share on other sites



    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
    Add a comment...

    ×   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.


  • Status Definitions

     

    Open = Under consideration.

     

    Solved = The issue has been resolved.

     

    Solved version = The issue has been resolved in the indicated release version.

     

    Closed = Feedback or opinion better posted on our forum for discussion. Also for reports we cannot reproduce or need more information. In this case just add a comment and we will review it again.

     

    Retest = Please retest in latest release.


    Priority Definitions

     

    Minor = Something not working correctly.

     

    Urgent = Server crash, data loss, or other showstopper.

     

    Annoyance = Doesn't affect functionality but should be fixed.

     

    Other = Announcement or other non-issue.