.png)
Ich habe einsehr alt(Ich glaube, ca. 2009) Mac Mini, der heutzutage praktisch nur als NAS für unsere TimeMachine-Backups fungiert. Er funktionierte einwandfrei, bis vor etwa 2 Tagen, als diese Backups plötzlich nicht mehr funktionierten. Ich konnte auch keine Verbindung über Share Screen herstellen. Als ich es versuchte ssh, stellte ich fest, dass er liefsehr langsam. Es dauert 3-5 Minuten, bis ich sshmich einlogge. Meistens läuft das ab, aber wenn ich tatsächlich eine Verbindung herstellen kann, bleibt sie bestehen ... es ist einfach sehr langsam. Sogar herauszufinden, dass ich El Capitain verwende, dauerte fast 6 Minuten:
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
Der Betrieb topdauert problemlos 1–2 Minuten, bevor die Ausgabe beginnt (dann scheint die Ausgabe jedoch im normalen Tempo aktualisiert zu werden).
Ich nehme an, dass es etwas tut, aber ... ich kann nicht sagen, was. topWenn es läuft, sieht es ungefähr so aus:
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
...
und für mich sieht es so aus, als wäre die Welt in Ordnung.
Was auch immer passiert, es scheint über der Netzwerkschicht zu liegen, denn ich habe beispielsweise pingbeim Versuch , kontinuierlich ausgeführt which grep. Ich habe nach 100 Paketen angehalten, aber es war schnell und es wurden keine Pakete verloren:
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
Der whichBefehl hingegen ...
Krotos:~ cwr$ time which grep
/usr/bin/grep
real 1m10.675s
user 0m0.007s
sys 0m0.005s
Auch der Speicherplatz scheint in Ordnung zu sein, es dauert jedoch ewig, das herauszufinden:
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
Ich könnte mir wohl von jemandem einen Monitor leihen und ihn anschließen, aber ich würde das wirklich gerne über die Befehlszeile diagnostizieren können. Ich habe versucht, neu zu starten, aber das Problem besteht weiterhin. Vielleicht macht es einfach eines dieser mysteriösen MacOS-Dinge, wie die Neuindizierung der Spotlight-Datenbank oder so etwas, und in ein paar Tagen ist alles wieder in Ordnung, wenn es fertig ist mit dem, was es gerade macht, aber ... ich würde gerne wissen, was (und ob das stimmt und ich einfach ein paar Tage warten sollte, oder ob es ein größeres Problem ist, das nicht einfach verschwindet).
Was kann ich sonst noch untersuchen, um herauszufinden, warum einfache Befehle mehrere Minuten dauern, wenn die CPU scheinbar fast vollständig im Leerlauf ist und ausreichend Arbeitsspeicher und Festplattenspeicher vorhanden sind?