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?
diskutil verifyDiskordiskutil verifyVolumeto 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:30ps -Avorps -Avrshow 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