• [6.8.0] <wsdd high cpu>


    diyjeff
    • Solved Minor

    Just noticed that on the Dashboard one cpu at a time goes to 100%.  Running top shows wsdd taking 100% (I am assuming that means 100% on one processor).  It jumps around to both regular and HT processors, all of which are not pinned to a VM.  It does not seem to be impacting any function or performance; I have not seen this before upgrading to 6.8.0.  I do not see any issues in the system log.

    • Thanks 3



    User Feedback

    Recommended Comments



    I’ll check my windows machines. I run 6.9.0 rc2 since i have a h470 motherboard. Needed for drivers. I was quiet surprised these are not yet available in the stable release. Makes me worry a bit about patch/update policy as well.

     

    Luckily there is a nice community around unraid.

    Link to comment
    42 minutes ago, Hoopster said:

    The WSD Daemon (wsdd) is not developed by Limetech.  They have merely chosen to implement it in unRAID for those who wish to have an alternative to SMB/netBIOS for network discovery.  There is probably not much they can do to fix this issue unless it is proven to be some interaction with wsdd and core unRAID services that causes the problem.

     

    I have completely disabled SMB v1 on all my Windows clients and am using WSD exclusively.  The -i br0 parameter has worked for me to mostly prevent the single-core 100% CPU usage issue.  Every 3-4 months it may pop up, but a reboot fixes it (or the stop array, disable WSD, start array enable WSD procedure).

    Well if you suffer from this every 3-4 month your statistics is that you don't really know how much the `-i br0` solve this or just reduce the rate. I have different experience, I can get this even few minutes after server restart, but also could reach 70 days without problems. For me the `-i br0` did not change anything.

     

     

    35 minutes ago, BRiT said:

    There is a patch for newer version of WSDD to remove infinite loop under certain conditions. It was mentioned in one of these threads. 

     

    Limetech could release patches / updates for their stable 6.8 build but they seem to have forgone that for a long time now to put out 6.9 beta and RCs.

    I have posted it somewhere, but even trying to get a feedback from @limetechwhat version of WSDD they used for latest RC did not get any response. I do hope it is getting the attention it should before final release.

    Link to comment
    6 minutes ago, thecode said:

    `-i br0` solve this or just reduce the rate.

    Right, this is not a solution as it does not completely prevent the issue, but it does certainly reduce by a lot how often I see the problem on my servers.

    • Like 1
    Link to comment

    Noticed this today. htop shows CPU1 at 100% culprit being WSDD. I'm going to try -i br0.

     

    I don't see how "Disable WSD" is a reasonable solutuion.

    Link to comment
    On 2/21/2021 at 1:01 PM, adminmat said:

    Noticed this today. htop shows CPU1 at 100% culprit being WSDD. I'm going to try -i br0.

     

    I don't see how "Disable WSD" is a reasonable solutuion.

    Also experienced this today. Trying the workaround.

    Link to comment

    I'm on 6.9.2 and noticed this on two of my UNRAID servers after noticing a lot of heat and fan noise.

    One is a Ryzen 5 5600X and the other is a Xeon 1270 v2, the -i br0 or -i bond0 depending on your network configuration does seem to resolve the issue.

    This really needs to be fixed, there are going to be a lot of UNRAID servers around the world unnecessarily draining power and generating heat because of this issue.

     

    Link to comment

    Just discovered this myself, unRAID 6.9.2 as well. One core, pegged to 100%, htop showing the offending process to be wsdd. Attempting to fix/bypass, but like DanW said, it may not be unRAID's bug, but if there is a more recent package that fixes it, it is your responsibility to test and merge it into unRAID to prevent a race condition inside your product. My CPU had hundreds of hours of time on that one thread until I noticed it just gobbling power and generating heat for no reason. Seems rather wasteful if you ask me.

    Link to comment

    Encountered this today as well by chance when updating my plugins and dockers. I haven't been looking into Unraid's GUI for a while so I have no idea since when it has been stuck at 100% on one core like that, it's a quad core and my usage of the dockers I use unraid to run is fairly light... and have not experience any of my services running any worse.
    Will try the suggested bandaid for now and try and keep a closer look on it.

    Link to comment
    On 3/16/2022 at 4:31 PM, chenyuejie said:

    Got same issue after upgrade to 6.10.0-rc3. 

    Meanwhile upgrade the mainboard bios and cpu from ryzen 2600 to ryzen 5700g.

    This problem is gone after I change CPU Isolation to 4 cores and restart server. I also add WSD options before which looks like not effect.

    Link to comment

    Saw the issue again today, on 6.9.2. I am using the -i br0 switch.

    -i br0


    Edit:
    Looks like this will be fixed in the future.

     

    Link to comment
    2 minutes ago, Iceman24 said:

    With 6.10, does this mean we can stop using the "-i br0" switch or would that still be recommended?

    Yes, I am on 6.11 now, but I already removed it in 6.10 from one of the servers and did not had any problem

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