0

I have a very old (I think circa 2009) Mac Mini, which effectively just acts as a NAS for our TimeMachine backups these days. It was working fine until about 2 days ago, when all of a sudden those backups stopped working. I also couldn't attach to it via Share Screen. When I tried ssh, I realized that it was running very slowly. It takes 3-5 minutes to ssh in. Mostly, those time out, but if I can actually get a connection to open, it stays open ... it's just very slow. Even figuring out that I was running El Capitain took almost 6 minutes:

Krotos:~ cwr$ time uname -a
Darwin Krotos.local 15.6.0 Darwin Kernel Version 15.6.0: Thu Jun 21 20:07:40 PDT 2018; root:xnu-3248.73.11~1/RELEASE_X86_64 x86_64

real    5m58.602s
user    0m0.007s
sys 0m0.007s

running top takes easily 1-2 minutes before output starts (but then output seems to update at the normal pace).

I assume it's doing something, but ... I can't tell what. top, when it gets up and running, looks something like this:

Processes: 90 total, 2 running, 17 stuck, 71 sleeping, 365 threads     09:49:05
Load Avg: 1.07, 1.10, 1.07  CPU usage: 0.97% user, 0.48% sys, 98.54% idle
SharedLibs: 100M resident, 6980K data, 45M linkedit.
MemRegions: 30832 total, 775M resident, 53M private, 153M shared.
PhysMem: 2098M used (1007M wired), 6350M unused.
VM: 286G vsize, 535M framework vsize, 0(0) swapins, 0(0) swapouts.
Networks: packets: 8361/986K in, 1770/314K out.
Disks: 11164/837M read, 2740/43M written.

PID  COMMAND      %CPU TIME     #TH   #WQ  #POR MEM    PURG   CMPR PGRP PPID
281  AppleFileSer 0.0  00:00.20 8     0    78   13M    8192B  0B   281  1
280  top          1.2  00:02.98 1/1   0    22   3044K  0B     0B   280  222
278- fpsaud       0.0  00:00.13 1     0    2    80K    0B     0B   278  1
270  ocspd        0.0  00:00.22 2     0    30   7376K  0B     0B   270  1
269  makewhatis   0.0  00:00.03 1     0    12   584K   0B     0B   245  267
267  sh           0.0  00:00.01 1     0    17   652K   0B     0B   245  2
...

which, to me, looks like all is well with the world.

Whatever is happening, it appears to be above the network layer, because, for example, I ran continuous ping while trying to which grep. I stopped after 100 packets, but it was both fast and didn't drop any:

64 bytes from 192.168.1.10: icmp_seq=101 ttl=64 time=1.315 ms
^C
--- krotos.local ping statistics ---
102 packets transmitted, 102 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.096/1.927/3.488/0.472 ms

The which command, on the other hand ...

Krotos:~ cwr$ time which grep
/usr/bin/grep

real    1m10.675s
user    0m0.007s
sys 0m0.005s

Disk space also seems fine, though it takes forever to figure that out:

Krotos:~ cwr$ time df
Filesystem    512-blocks      Used Available Capacity  iused    ifree %iused  Mounted on
/dev/disk0s2   232762432 119458488 112791944    52% 14996309 14098993   52%   /
devfs                383       383         0   100%      664        0  100%   /dev
map -hosts             0         0         0   100%        0        0  100%   /net
map auto_home          0         0         0   100%        0        0  100%   /home

real    3m4.875s
user    0m0.007s
sys 0m0.007s

I suppose I could go borrow a monitor from someone and plug it in, but, I'd really like to be able to diagnose this from the command line. I've tried rebooting, and the problem persists. Maybe it's just doing one of those mysterious MacOS things, like re-indexing the spotlight database or something, and it'll be fine in a few days when it finishes doing whatever it's doing, but ... I'd like to know what (and whether that's true and I should just wait a few days, or if it's some bigger problem that won't just go away).

What else can I look at to figure out why simple commands take multiple minutes when the CPU seems to be almost entirely idle and there's plenty of memory and plenty of disk space?

3
  • Circa 2009 mac mini with an original spindle?? disk - @philolegein - if that's the case you are having amazing luck .. I have lots of newer mac minis in the field and the disk is by far and away the thing most likely to fail, followed by power supply in some models (especially if as a model they ran hot), followed by logic board.
    – Mr R
    Apr 25 at 6:25
  • 2
    Perhaps try diskutil verifyDisk or diskutil verifyVolume to see if that helps (you'll need to add params) - but you might just have a "close to dead" disk.
    – Mr R
    Apr 25 at 6:30
  • Does the output of ps -Av or ps -Avr show anything using a lot of memory or cpu respectively? Otherwise as Mr R mentioned it could be the HDD failing. You could try checking the SMART status of the HDD with this solution apple.stackexchange.com/a/135566/43053 but in my experience HDD failures aren't guaranteed to show up as SMART errors.
    – Scottmeup
    Apr 25 at 6:36

You must log in to answer this question.

Browse other questions tagged .