wsdd 100% using 1 core


Recommended Posts

  • 1 month later...

I'm seeing this now on a brand new (to unraid) system running 6.8.3.   It's a trial key with only 2 drives and no additional setup--no vm's, no docker setup, not even any plugins installed or any data loaded/shares.

 

So likely this is more basic than suggested above.   Note, I don't have this issue on my primary production system, so maybe it's cpu generation based or some other hardware interaction.

 

FWIW, old system is 2x AMD 2431 on a Supermicro H8dm8-2,   new system is 1x AMD 6274 and Supermicro H8DG6.

 

 

Link to comment

I now get this happening regularly on a Lenovo Thinkstation E31 (Xeon E3-1225v2), never happened in 8 years continuous running on my old HP Microserver N36L.  Have been running unraid 24x7 since 2011 (originally version 4.7, currently 6.8.3 on a Basic license) and never had the problem until moving to the new hardware about 4 months ago.  Same installation - I just moved the USB drive and all the disks across to the Thinkstation and the problem started and has been recurring since then.  Stopping then restarting the array fixes it for a few days or weeks, then it comes back again.  :(

Link to comment
6 minutes ago, tj80 said:

I now get this happening regularly on a Lenovo Thinkstation E31

WS Discovery (the wsdd process) did not even exist until version 6.8 of unRAID so you could not have had this problem until moving to that version of the OS, regardless of hardware configuration.

 

There is nothing so far that indicates the problem is hardware related so I don't think your move to the Thinkstation was the trigger for the problem. 

 

If you are not using WS Discovery, you can always disable it in SMB settings and the problem is guaranteed to disappear.

 

 

Link to comment
  • 1 month later...

WS discovery is a welcome convenience on my network and I would prefer to leave it running, is it possible to maybe lock it to a specific core to play more nicely with Docker and VM CPU Pinning settings?

 

As it stands, I use CPU pinning to give VM's and Docker Containers access to certain cores to help with higher CPU dependent things like a game server or Plex container, so it would be nice to just throw WS Discovery on specific cores that aren't shared with the CPU dependent stuff.

Link to comment
3 minutes ago, axipher said:

WS discovery is a welcome convenience on my network and I would prefer to leave it running, is it possible to maybe lock it to a specific core to play more nicely with Docker and VM CPU Pinning settings?

 

As it stands, I use CPU pinning to give VM's and Docker Containers access to certain cores to help with higher CPU dependent things like a game server or Plex container, so it would be nice to just throw WS Discovery on specific cores that aren't shared with the CPU dependent stuff.

There isn't a way to specify a core for this function. Additionally, when the issue happens, the core that is at 100% may hoop to another core.

Link to comment
  • 1 month later...
On 8/15/2020 at 9:00 PM, trevisthomas said:

Same problem, 6.9 beta 25.  

 

Shutting down Docker made it stop.  I only have one container in there and it wasn't even started.

Same here. Shutting down docker (in the settings page->docker) fixed it here, too. Strange because all containers were stopped already, so it must be something with the docker service itself.

Edited by Videodr0me
Link to comment
  • 2 weeks later...
  • 1 month later...
  • 1 month later...
  • 1 month later...

This is happening to me too on v6.8.3

 

i followed the guy above who got the process id from top, killed it and typed wsdd to restart. The process had been running for a while. It seems to have cleared the issue for now but I guess the only perm fix is to disable WSD in the samba settings (need to stop the array to change it)

Link to comment

Have all of you with this issue tried the WSD Options setting mentioned in the bug report thread for this problem?

 

Adding -i br0 to the WSD Options has largely eliminated this problem for me. It is not completely gone but I only see it every 3-4 months or so now.  It's not a fix as it still can occur, but for many it at least greatly lessens the frequency with which the 100% CPU problem occurs.  YMMV.

 

image.thumb.png.8b91ebb563e2938848966c289846c588.png

Link to comment
18 hours ago, BRiT said:

Disabling WSDD prevents the problem 100% of the time...

Yes, it does, but, I prefer it over NetBIOS/SMB v1.0 so I disable those instead on unRAID and all Windows clients and run WSDD. 

 

Overall (even with the occasional 100% CPU issue) it has been more reliable in my network than trying to keep SMB v1.0 running despite Microsoft's best attempts to kill it.

Edited by Hoopster
Link to comment

My "solution" is this script (executed every 5 minutes):

 

#!/bin/bash
# #####################################
# Script:      WSDD Restarter
# Description: Restarts WSDD if its CPU usage is too high
# Author:      Marc Gutt
# 
# Changelog:
# 0.1
# - first release
# 
# ######### Settings ##################
wsdd_cpu_limit=5.0
# #####################################
# 
# ######### Script ####################
# make script race condition safe
if [[ -d "/tmp/${0///}" ]] || ! mkdir "/tmp/${0///}"; then exit 1; fi; trap 'rmdir "/tmp/${0///}"' EXIT;
# get pid and cpu usage
wsdd_pid=$(pidof wsdd)
if [ $? -eq 0 ]; then
    # check cpu usage
    wsdd_cpu_usage=$(ps -p ${wsdd_pid} -o %cpu --noheader | xargs)
    if [ $? -eq 0 ]; then
        if $(awk 'BEGIN {exit !('$wsdd_cpu_usage' >= '$wsdd_cpu_limit')}'); then # https://stackoverflow.com/a/45591665/318765
            samba restart
            /usr/local/emhttp/webGui/scripts/notify -i alert -s "WSDD restarted!" -d "CPU usage was too high!"
        fi
    fi
fi

 

  • Like 3
  • Haha 1
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.