DNS323 Slow speed + 100% CPU

[Jessy Hartman]

Dear All,

Hope you are all fine during these times...

I have a question regarding my DNS323 flashed with ALT-F.

CPU is always at 100% usage but I dont understand why as I have nothing running in bg...

Moreover, network speed is very slow : From my Mac, it take 1 minute just to open a folder !

Any idea ?

Best regards,

JH

[Jessy Hartman]

I can add that the slowliness occur only from my Mac but I've just tested from a random Windows and I can navigate in all folder with no delay. I dont understand why. They are all on the same switch...

Best regards,

JH

[Joao Cardoso]

On Friday, March 20, 2020 at 1:54:48 AM UTC, Jessy Hartman wrote:

Le vendredi 20 mars 2020 02:26:53 UTC+1, Jessy Hartman a écrit :

Dear All,

Hope you are all fine during these times...

I have a question regarding my DNS323 flashed with ALT-F.

CPU is always at 100% usage but I dont understand why as I have nothing running in bg...

 

Try looking at the processes that is consuming CPU, System->Utilities, View Logs, Running Process. The COMMAND with the high CPU% is at the top.

Moreover, network speed is very slow : From my Mac, it take 1 minute just to open a folder !

Any idea ?

I can add that the slowliness occur only from my Mac but I've just tested from a random Windows and I can navigate in all folder with no delay. I dont understand why.

Do you have the netatalk (AFP (Apple Filling Protocol) Server) package installed and the service running? It might be that the mac is using that by default, instead of using smb/Samba as the windows pc does? 

[Jessy Hartman]

Thanks for your help :-)

PID  PPID USER     STAT   VSZ %VSZ %CPU COMMAND
 3130   646 gepeto   R    11316  19%  80% smbd -D
 3442  3423 root     R     1200   2%  20% top -bn1
  683   646 root     S    10384  17%   0% smbd -D
  646     1 root     S    10336  17%   0% smbd -D
  643     1 root     S    10064  17%   0% nmbd -D
  556     1 root     S     1936   3%   0% smartd -i 1800
 3423  3422 root     S     1272   2%   0% {sys_utils_proc.} /bin/sh sys_utils_proc.cgi
  486     1 root     S     1224   2%   0% syslogd -C -m 0 -D
  603     1 root     S     1216   2%   0% crond
 3422   591 root     S     1216   2%   0% httpd -ifh /usr/www
    1     0 root     S     1204   2%   0% init
  591     1 root     S     1204   2%   0% inetd
  892     1 root     S     1204   2%   0% /bin/sh --
  893     1 root     S     1200   2%   0% {watch-inetd.sh} /bin/sh /usr/sbin/watch-inetd.sh
  489     1 root     S     1192   2%   0% klogd
 2764   893 root     S     1188   2%   0% sleep 180
  533     1 root     S      592   1%   0% sysctrl

As I can see, when I connect the Mac, a process start and even If I do nothing just connect the Mac, it go to 80%. That's crazy.

[Jessy Hartman]

Moreover, when I "eject" the NAS from the Mac, it goes back to normal stats... I try to connect via a Windows PC and the stats stay normal. Don't understand what happen when the Mac connect to it ?

[Joao Cardoso]

On Saturday, March 21, 2020 at 1:00:43 AM UTC, Jessy Hartman wrote:

Moreover, when I "eject" the NAS from the Mac, it goes back to normal stats... I try to connect via a Windows PC and the stats stay normal. Don't understand what happen when the Mac connect to it ?

Probably a Time Machine backup? Or a stale samba request? The process  consuming cpu is smb/samba, and is running under 'gepeto' user.

In the bottom of the status page the active samba shares are shown. For more detail you have to login the box and issue the command 'smbstatus', that will give more info, namely the file(s) being transferred or locked.

[Jessy Hartman]

Thanks for your help !

It seems that the mac try to do something but I don't understand what exactly, then the box CPU go to 100%... To stop that, I eject the box from the Mac and restart the Finder.

Is the Mac trying to "index" the box ?

[João Cardoso]

On Sunday, 22 March 2020 17:36:27 UTC, Jessy Hartman wrote:

Thanks for your help !

It seems that the mac try to do something but I don't understand what exactly, then the box CPU go to 100%... To stop that, I eject the box from the Mac and restart the Finder.

Is the Mac trying to "index" the box ?

I don't know. I don't have a mac.

You can try to google for '._.DS_Store NAS', which is the locked file. You will find many info regarding DS_Store and samba and lock files, but I can't help further.

[Jessy Hartman]

Thanks !

I've see that there is a lot of subject regarding "samba" and DENY_NONE or LOCKED FILES.

Hope I will find something. Maybe I have to change some settings in the Samba config ?

[Craig Holcomb]

I would like to see the lines that are above what you have pasted here.  I am particularly interested to know your io percentage.  When I experience this problem it apparently goes very high and may be related to what is described in the Performance section of this page.  As that web page suggests using htop for diagnosing I installed it using the Alt-F package manager. htop showed that my CPU was not at 100% (somewhat in conflict with what the Status page shows) but did show that the largest percentage of CPU being used is for io-wait.  I'm still trying to find more information on this but would like to know if your CPU usage is similarly based.

[Jessy Hartman]

Sure !

So, this is when I do nothing, no Mac and no PC connected to the files :

Mem: 58684K used, 1972K free, 0K shrd, 2904K buff, 721556K cached
CPU:   0% usr 100% sys   0% nic   0% idle   0% io   0% irq   0% sirq
Load average: 0.30 0.07 0.02 2/68 1046
  PID  PPID USER     STAT   VSZ %VSZ %CPU COMMAND
 1025  1024 root     R     9552  16%  90% smbstatus -S
 1045  1022 root     R     1200   2%  10% top -bn1
 2775   646 root     S    11320  19%   0% smbd -D
  683   646 root     S    10508  17%   0% smbd -D
  646     1 root     S    10336  17%   0% smbd -D
  643     1 root     S    10064  17%   0% nmbd -D
  556     1 root     S     1936   3%   0% smartd -i 1800
  549     1 root     S     1288   2%   0% {status.cgi} /bin/sh status.cgi
 1024   549 root     S     1288   2%   0% {status.cgi} /bin/sh status.cgi
 1022  1021 root     S     1272   2%   0% {sys_utils_proc.} /bin/sh sys_utils_proc.cgi
  486     1 root     S     1224   2%   0% syslogd -C -m 0 -D
  603     1 root     S     1216   2%   0% crond
 1021   591 root     S     1216   2%   0% httpd -ifh /usr/www
    1     0 root     S     1204   2%   0% init
  591     1 root     S     1204   2%   0% inetd
  892     1 root     S     1204   2%   0% /bin/sh --
  893     1 root     S     1200   2%   0% {watch-inetd.sh} /bin/sh /usr/sbin/watch-inetd.sh
 1026  1024 root     S     1196   2%   0% tail -n +4
  489     1 root     S     1192   2%   0% klogd
  520   893 root     S     1188   2%   0% sleep 180
  533     1 root     S      592   1%   0% sysctrl

Mac connected to the files :

Mem: 59028K used, 1628K free, 0K shrd, 2772K buff, 721400K cached
CPU:  80% usr  20% sys   0% nic   0% idle   0% io   0% irq   0% sirq
Load average: 0.22 0.08 0.02 2/65 1145
  PID  PPID USER     STAT   VSZ %VSZ %CPU COMMAND
 2775   646 gepeto   R    11320  19%  80% smbd -D
 1144  1125 root     R     1200   2%  20% top -bn1
  683   646 root     S    10508  17%   0% smbd -D
  646     1 root     S    10336  17%   0% smbd -D
  643     1 root     S    10064  17%   0% nmbd -D
  556     1 root     S     1936   3%   0% smartd -i 1800
 1125  1124 root     S     1272   2%   0% {sys_utils_proc.} /bin/sh sys_utils_proc.cgi
  486     1 root     S     1224   2%   0% syslogd -C -m 0 -D
  603     1 root     S     1216   2%   0% crond
 1124   591 root     S     1216   2%   0% httpd -ifh /usr/www
    1     0 root     S     1204   2%   0% init
  591     1 root     S     1204   2%   0% inetd
  892     1 root     S     1204   2%   0% /bin/sh --
  893     1 root     S     1200   2%   0% {watch-inetd.sh} /bin/sh /usr/sbin/watch-inetd.sh
  489     1 root     S     1192   2%   0% klogd
  520   893 root     S     1188   2%   0% sleep 180
  533     1 root     S      592   1%   0% sysctrl

Mac copying a zip file (60mo) : (I Stop the copy cause it take a looooong time and will never finish in an hour)

Mem: 58572K used, 2084K free, 0K shrd, 2772K buff, 721400K cached
CPU:  78% usr  21% sys   0% nic   0% idle   0% io   0% irq   0% sirq
Load average: 0.92 0.36 0.13 2/65 1841
  PID  PPID USER     STAT   VSZ %VSZ %CPU COMMAND
 2775   646 gepeto   R    11348  19%  76% smbd -D
 1840  1821 root     R     1200   2%  18% top -bn1
  643     1 root     S    10064  17%   6% nmbd -D
  683   646 root     S    10508  17%   0% smbd -D
  646     1 root     S    10336  17%   0% smbd -D
  556     1 root     S     1936   3%   0% smartd -i 1800
 1821  1820 root     S     1272   2%   0% {sys_utils_proc.} /bin/sh sys_utils_proc.cgi
  486     1 root     S     1224   2%   0% syslogd -C -m 0 -D
  603     1 root     S     1216   2%   0% crond
 1820   591 root     S     1216   2%   0% httpd -ifh /usr/www
    1     0 root     S     1204   2%   0% init
  591     1 root     S     1204   2%   0% inetd
  892     1 root     S     1204   2%   0% /bin/sh --
  893     1 root     S     1200   2%   0% {watch-inetd.sh} /bin/sh /usr/sbin/watch-inetd.sh
  489     1 root     S     1192   2%   0% klogd
 1204   893 root     S     1188   2%   0% sleep 180
  533     1 root     S      592   1%   0% sysctrl


If needed I can post the same story but instead of Mac I can try with a PC, and everything will work flawless. This issue came only from Mac, I'm still trying to understand what happen here.

Regards

[João Cardoso]

I think that you should put this question on a mac forum.

From what I read, there are two approaches, one on the samba server and other on the mac.

On the mac you have to issue a command so that it stops creating the DS_Store files on the samba shares.

On the samba server, by adding a 'veto' directive on the share definition, but only after removing the offending files; according to the samba manual this option impacts performance:

      veto files (S)

          This is a list of files and directories that are neither visible nor
          accessible. Each entry in the list must be separated by a '/', which allows
          spaces to be included in the entry. '*' and '?' can be used to specify
          multiple files or directories as in DOS wildcards.

          Each entry must be a unix path, not a DOS path and must not include the unix
          directory separator '/'.

          Note that the case sensitive option is applicable in vetoing files.

          One feature of the veto files parameter that it is important to be aware of is
          Samba's behaviour when trying to delete a directory. If a directory that is to
          be deleted contains nothing but veto files this deletion will fail unless you
          also set the delete veto files parameter to yes.

          Setting this parameter will affect the performance of Samba, as it will be
          forced to check all files and directories for a match as they are scanned.

          Examples of use include:

              ; Veto any files containing the word Security,
              ; any ending in .tmp, and any directory containing the
              ; word root.
              veto files = /*Security*/*.tmp/*root*/

              ; Veto the Apple specific files that a NetAtalk server
              ; creates.
              veto files = /.AppleDouble/.bin/.AppleDesktop/Network Trash Folder/

          Default: veto files =  # No files or directories are vetoed

There is another "delete veto" directive documented:

    delete veto files (S)

          This option is used when Samba is attempting to delete a directory that
          contains one or more vetoed directories (see the veto files option). If this
          option is set to no (the default) then if a vetoed directory contains any
          non-vetoed files or directories then the directory delete will fail. This is
          usually what you want.

          If this option is set to yes, then Samba will attempt to recursively delete
          any files and directories within the vetoed directory. This can be useful for
          integration with file serving systems such as NetAtalk which create meta-files
          within directories you might normally veto DOS/Windows users from seeing (e.g.
          .AppleDouble)

          Setting delete veto files = yes allows these directories to be transparently
          deleted when the parent directory is deleted (so long as the user has
          permissions to do so).

          Default: delete veto files = no

as the file is locked, disabling 'oplocks' (client (mac) opportunistic locks) on the share is also possible. Disabling it also affects performance.

 

[Craig Holcomb]

Thanks for posting that information.  It does not look like the same issue I am having (or, at least your usage looks different).  My load is much much higher than yours and my io % shows a high number.  Your io % stays zero in every case but I would like to see the same information when you copy with a PC.  Maybe your io would show an amount above zero but that wouldn't really tell me anything though you would have a possible baseline to compare when it works with when it doesn't.  Do you use the gepeto userid from the PC or do you just use gepeto from the Mac and use a different userid from the PC?

[David Albert]

I am a recent convert to Alt-F and it is awesome. It has breathed new life into a DNS-321 I'd long ago shelved.  I'm using it with two WDC WD40EFZX-68AWUN0 NAS drives configured as RAID1.

I also experienced a persistent slowness after I'd started transferring large amounts (~630GB) of data from another NAS into the Alt-F NAS public/RW folder.  Transfer rates slowed to a crawl and then virtually stopped.  More importantly, it stayed stuck in that state for days.  top showed one of the smbd instances with 431% VSZ, io was at 50% and smbd was consuming CPU even when the NAS was idle.  The GUI always showed the CPU at 100% and Load at 3.x. 

Mem: 59256K used, 1400K free, 0K shrd, 3080K buff, 721756K cached
CPU:   0% usr  46% sys   0% nic   0% idle  50% io   0% irq   3% sirq
Load average: 2.47 3.04 3.19 4/72 2618

  PID  PPID USER     STAT   VSZ %VSZ %CPU COMMAND

 2601  2276 dalbert  R     1204   2%  11% top
 2816   829 root     R    17412  29%   9% smbd -D
 2766   829 root     D     255m 431%   7% smbd -D
 1151     1 root     R      596   1%   5% sysctrl
 2004     2 root     SW       0   0%   5% [kworker/0:0]
 3587   829 root     S    41432  68%   2% smbd -D

 Rebooting the NAS cleared the problem.
Unfortunately, I didn't check smbstatus before rebooting...if it happens again, I'll do that.

[Craig Holcomb]

If your reboot included FSCK then it is probable that your file system just needed cleaned up like mine did. Here is my last posting on another thread that I had started when I thought the slowness I was experiencing was an NFS problem:

On Sunday, October 25, 2020 at 1:16:25 PM UTC-5 Craig Holcomb wrote:

Yesterday the SMR drive finally started writing at an acceptable speed again and I'm pretty sure my actions caused that improvement.  My idea of waiting for drive cache and rewrites of previously deleted areas was a waste of time.  What seems to have solved the problem was FSCK.   I hadn't really paid much attention to the Status Page's information on number of day's until it would run FSCK automatically.  It had obviously been trying to tell me something for a very long time as all devices were sitting in the negative 100+ range (and the numbers were in a nice red font, duh).   I navigated to the Filesystem Maintenance Page and selected Check from the FS Operations drop down for my three main devices.  Between the three of them it took quite a long time to complete but we're talking about approximately 12 terabytes so the time it took does not seem unreasonable.  The last time I wrote data to the SMR drive prior to running FSCK it was getting so bad it took roughly 5 days to write 6 gigabytes.  After running FSCK I wrote approximately 13 gigabytes in 3 hours.  A vast improvement, no?  I'm hoping this is the solution I've been looking for and will only report back here if I experience future slowdowns that cannot be resolved this way.