SMBD saturates CPU

    • OMV 3.x

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • SMBD saturates CPU

      Hi all,
      For some reason, my OMV install is using 100% CPU with 22% on average for the SMBD daemon for a few days. When I stop the SMBD daemon, everything comes back to normal (2 to 4% CPU).
      Does anyone have an idea on how to correct that please?
      (I have Crashplan running within OMV but even when stopped, it odesn't change the CPU utilization, it is SMBD that gives this high CPU %)

    • I had a similar issue but I was using another NAS distro and I had symlinks setup on my media server, I finally found this which did resolve the problem, but it relates to later kernel builds.

      The thing that I found was if I rebooted the NAS the problem reappeared, if rebooted my media server as well the problem disappeared, I added the workaround to both smb conf files. It seems to happen when something is trying to access an smbd share in this case my media server with an error on the NAS Could not find child.....ignoring...the log was endless.
      Raid is not a backup! Would you go skydiving without a parachute?
    • Hi there, thanks for helping.
      Command "smbstatus" returns this:
      Samba version 4.2.14-Debian
      PID Username Group Machine Protocol Version

      Service pid machine Connected at

      No locked files

      Command cat "/var/log/messages | grep smb" returns nothing

      Geaves, I found the same URL you mention but the work around "deadtime = 0" does not work for me, unfortunately (I set it in my SMB options section of OMV)
    • Nope, none

      EDIT: the only error I see in the Syslog is related to Quota. Never paid attention to that before (not sure if I had the message previously or not). It says: "quotaon.service, main process exited status=10/n/a"

      EDIT2: may be another error message that appears strange: "charybde kernel: [ 1600.215192] perf interrupt took too long (10018 > 10000), lowering kernel.perf_event_max_sample_rate to 12500" (this happens while the Crashplan service was stopped, but the SMBD daemon was up and consuming its 20% CPU...)

      The post was edited 3 times, last by tugdualenligne2 ().

    • tugdualenligne2 wrote:

      Am I the only one having this issue?????

      EDIT: I just discovered that when I shutdown one of my other server which is uses my OMV box as a SMB server, the CPU load just disappear. So it must be my other server which stresses a bit too much my SMB server... Ideas, gents?
      This was similar to my would make sense why your smbstatus returned empty, in my case I had a nas and a media server which accessed the nas via symlinks. I started getting high cpu from smdb and couldn't work it out.
      If I rebooted the nas the problem went away only for it to reappear, but the interesting part was no connections showed in smbstatus....the only way I got over the problem if the nas running smdb was restarted the I had to restart the media as well, this stopped the high cpu and smbstatus populated with the current connections, including any windows machines.

      I never found a complete solution, but reboot one, reboot the other stopped it.
      Raid is not a backup! Would you go skydiving without a parachute?