[[6.8.0] <wsdd high cpu>]

Just happened to me last night. WSD started using 100% of a single core briefly after I had installed ShinobiPro docker, might be a co-incidence. Have not seen this before. The only syslog entries at that time were related to the docker networking:

Jun 28 23:17:14 TMS-740 kernel: docker0: port 16(vethf278871) entered blocking state
Jun 28 23:17:14 TMS-740 kernel: docker0: port 16(vethf278871) entered disabled state
Jun 28 23:17:14 TMS-740 kernel: device vethf278871 entered promiscuous mode
Jun 28 23:17:14 TMS-740 kernel: IPv6: ADDRCONF(NETDEV_UP): vethf278871: link is not ready
Jun 28 23:17:14 TMS-740 kernel: docker0: port 16(vethf278871) entered blocking state
Jun 28 23:17:14 TMS-740 kernel: docker0: port 16(vethf278871) entered forwarding state
Jun 28 23:17:14 TMS-740 kernel: docker0: port 16(vethf278871) entered disabled state
Jun 28 23:17:14 TMS-740 kernel: eth0: renamed from veth3b25ee7
Jun 28 23:17:14 TMS-740 kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethf278871: link becomes ready
Jun 28 23:17:14 TMS-740 kernel: docker0: port 16(vethf278871) entered blocking state
Jun 28 23:17:14 TMS-740 kernel: docker0: port 16(vethf278871) entered forwarding state
Jun 28 23:17:15 TMS-740 avahi-daemon[10892]: Joining mDNS multicast group on interface vethf278871.IPv6 with address fe80::5082:23ff:fedd:12af.
Jun 28 23:17:15 TMS-740 avahi-daemon[10892]: New relevant interface vethf278871.IPv6 for mDNS.
Jun 28 23:17:15 TMS-740 avahi-daemon[10892]: Registering new address record for fe80::5082:23ff:fedd:12af on vethf278871.*.

 

As a side note, server restart is not mandatory to recover from the issue; you can also stop the array, disable and re-enable the WSD daemon in settings and start the array. I just hate having my precious uptime resetting