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?

  • 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 '21 at 06: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 '21 at 06: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 https://apple.stackexchange.com/a/135566/43053 but in my experience HDD failures aren't guaranteed to show up as SMART errors. – Scottmeup Apr 25 '21 at 06:36

0 Answers0