Ich habe gerade festgestellt, dass Befehlszeilenprogramme wie ls( /bin/ls), touch( /usr/bin/touch), cat( /bin/cat) usw. sehr langsam sind, wenn ich sie über Terminal oder iTerm auf meinem MacBook ausführe. Zum Beispiel:
ls'in einem leeren Verzeichnis dauert 1 Sekunde (es dauert auch 1 Sekunde in einem nicht leeren Verzeichnis, sowohl mit vielen Dateien als auch mit wenigen Dateien);
touchDas Erstellen einer neuen Datei dauert 1 Sekunde (es dauert auch 1 Sekunde für toucheine vorhandene Datei);
catDas Laden einer leeren Datei dauert 1 Sekunde (es gibt auch eine Verzögerung von 1 Sekunde, bevor etwas passiert, wenn ich cateine nicht leere Datei verwende).
Ich habe versucht, dies auf viele Arten zu diagnostizieren, aber ohne Erfolg. Ich glaube nicht, dass dies ein Dateisystemproblem ist, da:
Ich habe das Festplattendienstprogramm ausgeführt und es meldet keine Probleme.
Im Finder scheint alles einwandfrei zu funktionieren, zB werden Verzeichnisinhalte sofort im Finder angezeigt.
Ich habe GNU Coreutils mit Homebrew installiert und versucht gls, gtouch, gcat, usw. zu verwenden, und alle oben aufgeführten Vorgänge werden sofort ausgeführt, wenn sie stattdessen mit der GNU-Version ausgeführt werden.
Irgendwelche Ideen, was los sein könnte? Irgendwelche Ideen, wie man das beheben kann?
BEARBEITEN: Wenn ich den Computer neu starte oder einen anderen Benutzer versuche, verschwinden diese Probleme vorübergehend, aber nach ein paar Minuten scheinen sie wieder aufzutauchen. Noch eine seltsame Sache, die mir aufgefallen ist:
$ time date
Wed Jan 28 10:07:11 PST 2015
real 0m0.151s
user 0m0.001s
sys 0m0.003s
$ time date
Wed Jan 28 10:07:13 PST 2015
real 0m0.029s
user 0m0.001s
sys 0m0.002s
$ time date
Wed Jan 28 10:07:16 PST 2015
real 0m1.005s
user 0m0.001s
sys 0m0.002s
$ time date
Wed Jan 28 10:07:18 PST 2015
real 0m1.005s
user 0m0.001s
sys 0m0.002s
Dies passiert bei allen Dienstprogrammen, die ich ausprobiert habe, mkdir, scp, sftp, more, cat, usw.: Das erste Mal, wenn ich es nach einem Neustart ausführe, ist es mittellangsam. Das zweite Mal, wenn ich es laufe, ist es irgendwie schnell. Alle folgenden Male, wenn ich es ausführe, ist es langsam.
Ich habe das Problem heute tatsächlich herausgefunden. Es wurde durch eine Anti-Malware-Software namens Sourcefire AMP (Advanced Malware Protection) verursacht . Alle meine Probleme verschwanden, nachdem ich es deaktiviert/deinstalliert hatte.
Ich vermute, dass es so etwas wie das Verzögern von Dingen in /bin, /usr/bin, usw. aus "Sicherheitsgründen" getan hat ... Ich vermute, dass die GNU-Tools nicht verzögert wurden, weil sie nicht in den "schwarzen" Verzeichnissen waren.
Das erste, was ich überprüfen würde, ist, dass Sie keine seltsamen $ PATH - Timings für eine Datei ausführen, die nicht existiert und die schnell sein sollte:
Mac:~ bmike$ time /bin/ls /private/xyz
ls: /private/xyz: No such file or directory
real 0m0.004s
user 0m0.001s
sys 0m0.002s
Mac:~ bmike$ time /bin/ls /private/tmp
com.apple.launchd.q2QmVhsPCV com.apple.launchd.zQ5EK6R6AZ
real 0m0.006s
user 0m0.002s
sys 0m0.003s
Das nächste wäre, das gesamte Systemgeschäft zu überprüfen:
Mac:~ bmike$ vm_stat 5
Mach Virtual Memory Statistics: (page size of 4096 bytes)
free active specul inactive throttle wired prgable faults copy 0fill reactive purged file-backed anonymous cmprssed cmprssor dcomprs comprs pageins pageout swapins swapouts
306160 1168138 79266 53096 0 299239 613825 20971811 345367 15995721 237 2472732 203216 1097284 328691 190541 260034 646113 623838 285 286101 299172
305613 1172072 79345 53098 0 295915 618898 1191 1 680 0 0 203297 1101218 328691 190541 0 0 0 0 0 0
306163 1188285 79345 53088 0 279370 621180 1055 0 600 0 0 203287 1117431 328682 190541 9 0 0 0 0 0
306039 1186031 79345 53088 0 281598 621176 729 0 293 0 0 203287 1115177 328664 190541 18 0 0 0 0 0
^C
Mac:~ bmike$ iostat 5
disk0 cpu load average
KB/t tps MB/s us sy id 1m 5m 15m
31.31 12 0.35 9 4 86 1.32 1.41 1.43
0.00 0 0.00 2 2 96 1.21 1.38 1.42
18.40 1 0.02 5 2 93 1.20 1.38 1.42
22.00 1 0.02 3 2 95 1.20 1.38 1.42
^C
Dann würde ich alle Anwendungen beenden und alle Benutzer abmelden und neu starten. Wenn Sie sich von Ihrem Mac anmelden lassen, deaktivieren Sie dies in den Systemeinstellungen, damit Sie sich nach dem Neustart sicher anmelden können. (Halten Sie die Umschalttaste sofort nach dem Drücken der Eingabetaste gedrückt, wenn Sie ein Kennwort eingeben, um sich bei Ihrem Benutzer anzumelden, oder halten Sie die Umschalttaste direkt nach der Auswahl Ihres Benutzersymbols gedrückt, wenn Sie kein Kennwort haben.)
Wiederholen Sie die Messungen (und optional das Timing der alternativen GNU-Tools), um festzustellen, ob das Problem vorübergehend oder systematisch ist.
time /bin/ls /non/existent/directoryist langsam. time /bin/ls /binist langsam.Ähnlich wie bei @bmike könnte Ihr $PATH etwas enthalten, das die Shell verzögert, bevor sie den Befehl findet, den Sie ausführen möchten. Neben dem dateBefehl timesollte auch explizit auf der Kommandozeile genannt werden.
Versuchen Sie /usr/bin/time /bin/dateund time dateein paar Mal hintereinander, um zu sehen, ob es einen Unterschied in der Ausgabe gibt. Wenn ja, dann echo $PATHsollte Ihnen das einen Hinweis darauf geben, was die Verzögerung verursacht.
timesowohl eine eingebaute Shell (bash) als auch eine Binärdatei ist, ist es möglicherweise besser, sich in allen Fällen an eine zu halten.timeswar eingebaut, aber nicht time. Ich kann jedoch nicht timeaufhören zu arbeiten, selbst nachdem ich meinen $PATH zerstört habe ... also haben Sie wahrscheinlich Recht. Trotzdem ist der Vergleich der Ausgabe von times /bin/dateund times datemöglicherweise insgesamt die beste Option, da timesdies eindeutig ist. (Interessanterweise geben time date, times date, und /usr/bin/time datedrei unterschiedlich formatierte Ausgaben zurück)type time, um herauszufinden, woher ein Befehl kommt :-)
kein Hang
time lsundtime touch foodas Ergebnis kopieren/in Ihre Frage einfügen?Kevin H. Lin
timeAusgabe sehr nahe an echten 0m1.004s, Benutzer 0m0.002s, System 0m0.002s, plus oder minus ~ 0.001s.Kevin H. Lin
Saaru Lindestøkke
Kevin H. Lin