10 votos

¿Por qué mis utilidades de línea de comandos funcionan tan lentamente en mi Mac?

Acabo de darme cuenta de que las utilidades de línea de comandos como ls ( /bin/ls ), touch ( /usr/bin/touch ), cat ( /bin/cat ), etc. son muy lentos cuando los ejecuto desde Terminal o iTerm en mi MacBook. Por ejemplo:

  • ls 'ing mientras está en un directorio vacío tarda 1 segundo (también tarda 1 segundo en un directorio no vacío, tanto con muchos archivos como con pocos);

  • touch 'ing un nuevo archivo tarda 1 segundo (también tarda 1 segundo en touch un archivo existente);

  • cat La creación de un archivo vacío tarda 1 segundo (también hay un retardo de 1 segundo antes de que ocurra algo cuando cat un archivo no vacío).

He tratado de diagnosticar esto de muchas maneras pero sin éxito. No creo que sea un problema del sistema de archivos, ya que:

  • He ejecutado la Utilidad de Discos y no informa de ningún problema.

  • Todo parece funcionar bien en Finder, por ejemplo, el contenido del directorio se muestra instantáneamente en Finder.

  • He instalado GNU coreutils usando Homebrew y he intentado usar gls , gtouch , gcat etc., y todas las operaciones que he enumerado anteriormente ocurren instantáneamente cuando se ejecutan con la versión GNU.

¿Alguna idea de lo que puede estar pasando? ¿Alguna idea sobre cómo solucionarlo?


EDITAR: Cuando reinicio el ordenador, o pruebo con otro usuario, estos problemas desaparecen temporalmente, pero al cabo de unos minutos parecen reaparecer de nuevo. Otra cosa extraña que he notado:

$ 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 ocurre con todas las utilidades que he probado, mkdir , scp , sftp , more , cat etc.: La primera vez que lo ejecuto después de un reinicio, es medianamente lento. La segunda vez que lo ejecuto, es medio-rápido. Todas las veces siguientes que lo ejecuto, es lento.

2 votos

¿Puedes correr time ls , time touch foo etc. y copiar/pegar el resultado en tu pregunta?

2 votos

@patrix: Para todos los casos que he enumerado, el time La salida es muy cercana a la real 0m1.004s, user 0m0.002s, sys 0m0.002s, más o menos ~0.001s.

0 votos

(Mientras que las versiones de GNU tienen en cambio un real de alrededor de 0m0.004s)

7voto

cmsjr Puntos 16766

Hoy he descubierto el problema. Fue causado por una pieza de software anti-malware llamado Sourcefire AMP (Advanced Malware Protection) . Todos mis problemas desaparecieron después de deshabilitarlo/desinstalarlo.

Supongo que estaba haciendo algo como poner un retraso en las cosas en /bin , /usr/bin etc. por "razones de seguridad"... Supongo que las herramientas GNU no se retrasaron porque no estaban en los directorios de la "lista negra".

3 votos

Me alegro de que lo hayas resuelto. Siéntase libre de aceptar su propia respuesta - puede ayudar a otros a resolver el mismo problema.

0 votos

La página www.sourcefire.com no está funcionando www.sourcefire.com no puede actualmente manejar esta solicitud. ERROR HTTP 503

2voto

Oskar Puntos 1242

Lo primero que yo comprobaría es que no tienes un extraño $PATH - tiempos de ejecución de un archivo que no existe y 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 comprobar la actividad 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

Entonces salía de todas las aplicaciones y cerraba la sesión de todos los usuarios y reiniciaba. Si su Mac le permite iniciar la sesión, desactívela en las preferencias del sistema para poder realizar un inicio de sesión seguro después del reinicio. (Mantenga la tecla de mayúsculas inmediatamente después de pulsar retorno si escribe una contraseña para iniciar la sesión de su usuario o mantenga pulsada la tecla de mayúsculas justo después de seleccionar el icono de su usuario si no tiene una contraseña).

Repite las mediciones (y opcionalmente cronometra las herramientas gnu alternativas) para saber si el problema es temporal o sistemático.

1 votos

También inicie la sesión como invitado o como un nuevo usuario y repita la sincronización

0 votos

time /bin/ls /non/existent/directory es lento. time /bin/ls /bin es lento.

0 votos

He actualizado mi pregunta con algunos detalles más...

1voto

Kent Puntos 3462

De manera similar a lo que dijo @bmike, tu $PATH podría tener algo en él que hace que el shell se retrase antes de encontrar el comando que estás tratando de ejecutar. Además del date comando, time también debe ser nombrado explícitamente en la línea de comandos.

Prueba con /usr/bin/time /bin/date y time date unas cuantas veces seguidas para ver si hay alguna diferencia en la salida. Si es así, entonces echo $PATH debería darte una pista sobre la causa del retraso.

0 votos

time es tanto un shell (bash) incorporado como un binario, podría ser mejor quedarse con uno en todos los casos.

0 votos

Interesante. Pensé que times estaba incorporado, pero no time . No puedo hacer time Sin embargo, dejó de funcionar, incluso después de destruir mi $PATH... así que, probablemente tengas razón. Sin embargo, comparando la salida de times /bin/date y times date podría ser la mejor opción en general porque times es inequívoco. (Es interesante, time date , times date y /usr/bin/time date devuelven tres salidas con formatos diferentes)

0 votos

También puede utilizar type time para saber de dónde viene un comando :-)

AppleAyuda.com

AppleAyuda es una comunidad de usuarios de los productos de Apple en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X