Acabo de notar que las utilidades de la línea de comandos como ls
( /bin/ls
), touch
( /usr/bin/touch
), cat
( /bin/cat
), etc. son muy lentas cuando las ejecuto desde Terminal o iTerm en mi MacBook. Por ejemplo:
ls
'ing while en un directorio vacío toma 1 segundo (también toma 1 segundo en un directorio no vacío, tanto con muchos archivos como con pocos archivos);
touch
'ing un archivo nuevo toma 1 segundo (también toma 1 segundo para touch
un archivo existente);
cat
'ing un archivo vacío toma 1 segundo (también hay un retraso de 1 segundo antes de que suceda algo cuando no tengo cat
un archivo vacío).
He intentado diagnosticar esto de muchas maneras, pero fue en vano. No creo que esto sea un problema del sistema de archivos, ya que:
He ejecutado la Utilidad de Discos y no reporta problemas.
Todo parece funcionar bien en Finder, por ejemplo, el contenido del directorio se muestra instantáneamente en Finder.
Instalé GNU coreutils usando Homebrew e intenté usar gls
, gtouch
, gcat
, etc., y todas las operaciones que enumeré anteriormente ocurren instantáneamente cuando se ejecutan con la versión GNU.
¿Alguna idea de lo que podría estar pasando? ¿Alguna idea sobre cómo solucionar este problema?
EDITAR: cuando reinicio la computadora o pruebo con un usuario diferente, estos problemas desaparecen temporalmente, pero después de unos minutos parecen volver a aparecer. Otra cosa extraña que noté:
$ 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
Esto sucede con todas las utilidades que he probado, mkdir
, scp
, sftp
, more
, cat
, etc.: La primera vez que lo ejecuto después de reiniciar, es medio-lento. La segunda vez que lo ejecuto, es bastante rápido. Todas las veces posteriores que lo ejecuto, es lento.
De hecho, descubrí el problema hoy. Fue causado por un software anti-malware llamado Sourcefire AMP (Advanced Malware Protection) . Todos mis problemas desaparecieron después de que lo deshabilité/desinstalé.
Supongo que estaba haciendo algo como retrasar cosas en /bin
, /usr/bin
, etc. por "razones de seguridad"... Supongo que las herramientas GNU no se retrasaron porque no estaban en los directorios "en la lista negra".
Lo primero que verificaría es que no tenga un $PATH extraño: ejecute los tiempos de un archivo que no existe y uno que debería ser rápido:
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
Lo siguiente sería verificar el negocio general del sistema:
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
Luego saldría de todas las aplicaciones, cerraría la sesión de todos los usuarios y reiniciaría. Si tiene su Mac inicia sesión, deshabilítelo en las preferencias del sistema para que pueda realizar un inicio de sesión seguro después del reinicio. (Mantenga presionada la tecla shift inmediatamente después de presionar regresar si escribe una contraseña para iniciar sesión en su usuario o mantenga presionada la tecla shift justo después de seleccionar su ícono de usuario si no tiene una contraseña).
Repita las mediciones (y, opcionalmente, cronometre las herramientas gnu alternativas) para saber si el problema es temporal o sistemático.
time /bin/ls /non/existent/directory
es lento. time /bin/ls /bin
es lento.Similar a lo que dijo @bmike, su $PATH podría tener algo que hace que el shell se demore antes de encontrar el comando que está tratando de ejecutar. Además del date
comando, time
también debe nombrarse explícitamente en la línea de comando.
Pruebe /usr/bin/time /bin/date
y time date
varias veces seguidas para ver si hay alguna diferencia en la salida. Si es así, echo $PATH
debería darte una pista de qué está causando el retraso.
time
es a la vez un shell (bash) incorporado y un binario, podría ser mejor ceñirse a uno en todos los casos.times
estaba incorporado, pero no time
. Sin embargo, no puedo hacer que time
deje de funcionar, incluso después de destruir mi $ PATH ... así que probablemente tengas razón. Sin embargo, comparar la salida de times /bin/date
y times date
podría ser la mejor opción en general porque times
es un hecho inequívoco. (Curiosamente, time date
, times date
y /usr/bin/time date
devuelven tres salidas con formato diferente)type time
para averiguar de dónde proviene un comando :-)
sin ladera
time ls
,time touch foo
etc. y copiar/pegar el resultado en tu pregunta?kevin h lin
time
salida es muy cercana a 0m1.004s reales, 0m0.002s de usuario, 0m0.002s sys, más o menos ~0.001s.kevin h lin
Saaru Lindestøkke
kevin h lin