No entiendo por qué lsof en mi Mac (10.8.2, MacBook Pro) es tan lento.
En mi Mac, lsof
toma más de un minuto:
$ touch /tmp/testfile
$ time lsof /tmp/testfile
real 1m16.483s
user 0m0.029s
sys 1m15.969s
En una caja típica de Linux, ejecutando Ubuntu 12.04, lsof
toma 20 ms:
$ touch /tmp/testfile
$ time lsof /tmp/testfile
real 0m0.023s
user 0m0.008s
sys 0m0.012s
El problema persiste si ejecuto lsof -n
(para evitar búsquedas de DNS). Además, traté de verificar qué llamadas al sistema se realizan lsof
usando dtruss
y descubrí que está llamando proc_info
decenas de miles de veces:
$ sudo dtruss lsof /tmp/testfile 2> /tmp/dump
$ cat /tmp/dump | sort | uniq -c | sort -nr | head
10000 proc_info(0x2, 0x1199, 0x8) = 1272 0
6876 proc_info(0x2, 0x45, 0x8) = 1272 0
2360 proc_info(0x2, 0x190D, 0x8) = 1272 0
1294 proc_info(0x2, 0xFF, 0x8) = 1272 0
1152 proc_info(0x2, 0x474, 0x8) = 1272 0
1079 proc_info(0x2, 0x2F, 0x8) = 1272 0
709 proc_info(0x2, 0xFE, 0x8) = 1272 0
693 proc_info(0x2, 0x1F, 0x8) = 1272 0
623 proc_info(0x2, 0x11A, 0x8) = 1272 0
528 proc_info(0x2, 0xF7, 0x8) = 1272 0
¿Algunas ideas? Realicé estas pruebas y obtuve los mismos resultados utilizando tanto la versión lsof
incluida con OS X (4.85) como la última versión de ftp://sunsite.ualberta.ca/pub/Mirror/lsof/ (4.87).
(Para los curiosos, la razón por la que estoy frustrado por este rendimiento es que cuando arrastro imágenes a Evernote, se ejecuta lsof
en el proceso de copiar el archivo, lo que hace que mi sistema se cuelgue durante un minuto completo cada vez que intento insertar una imagen en Evernote).
Según mi experiencia, desde Mac OS X 10.7 (Lion) hasta 10.11.5 (EI Capitan), lsof
siempre se bloquea.
Para resolver el problema, agregue la -n
opción.
lsof -n
Según manual de lsof
, la -n
opción:
inhibits the conversion of network numbers to host names for network files.
Inhibiting conversion may make lsof run faster. It is also useful when host
name lookup is not working properly
EDITAR 2018-04-25: si todavía es lento, puede intentarlo
-O to bypass the strategy it uses to avoid being blocked by some kernel operations
-P to inhibits the conversion of port numbers to port names for network files
-l to inhibits the conversion of user ID numbers to login names
La mejor manera de averiguar por qué es tan lento es ejecutar la herramienta "Instrumentos" (desde el icono de búsqueda de Spotlight en la esquina superior derecha) para hacer un "Rastreo del sistema" en /usr/sbin/lsof y luego ver el gráfico y las llamadas al sistema.
-n
cortar mi lsof +D
abajo de 5.31 real
a 0.25 real
. Esta opción es para... realCreo que la mayor parte del problema es que macOS se está volviendo cada vez más ridículo con la hinchazón y las capas innecesarias de marcos de trabajo derrochadores. Esto ha significado cientos de procesos adicionales y miles de archivos adicionales que se mantienen abiertos, lo que aumenta la cantidad de trabajo lsof
que tiene que hacer en al menos un orden de magnitud, y quizás más como dos órdenes.
lsof
pasó de una velocidad razonable a una lentitud atroz entre las 10.6 y las 10.13.
Aquí, en un sistema 10.13.4 actual, veo lo siguiente con solo 7 aplicaciones abiertas y en ejecución (Terminal, Chrome, Calendar, Finder, Adium, IPGadget y Stickies). (Chrome tiene 7 ventanas, con quizás 10 pestañas cada una).
# ps ax | wc -l
401
# time lsof -lnP | wc -l
10976
real 0m49.684s
user 0m0.250s
sys 0m40.172s
Durante la ejecución, ambas CPU superan con creces el 50 % del tiempo del sistema
Agregar -O
ayuda a veces, especialmente si lsof
no se ha ejecutado últimamente, pero lo mejor que he visto fue un ahorro del 10%. Por lo general, es minúsculo y probablemente no valga la pena los riesgos descritos en la página del manual:
# time lsof -lnPO | wc -l
10994
real 0m47.482s
user 0m0.249s
sys 0m40.472s
dtruss
afirma que hay más de 89,000 llamadas proc_info()
con mi carga de proceso actual, y esas están en el kernel, y como time
informa, la gran mayoría del tiempo invertido está en el kernel. No sé por qué hay alrededor de 8 llamadas por archivo abierto.
Lamentablemente macOS/Darwin no incluye el fstat
comando BSD cada vez más útil y eficiente.
No tengo una gran respuesta de por qué su sistema parece tardar un minuto más que mi Mac más lenta en llamar proc_info
30 mil veces, pero su tiempo muestra que tanto Linux como OS X están en el rango de 10 ms para que el usuario ejecute lsof. ¿Puedes reproducir ese lento arranque en modo seguro para descartar otras cargas en tu CPU?
Probé tres Mac y las que ejecutan 10.7.5 son aproximadamente un segundo más rápidas que mi Mac 10.8.2. Los sistemas operativos más antiguos son procesadores Core 2 Duo más lentos y creo que una Mac i7 que ejecuta el sistema operativo más nuevo sería tan rápida o más rápida que el sistema operativo y la CPU más antiguos, pero estaría equivocado.
Todas las máquinas realizan aproximadamente la misma cantidad de llamadas a proc_info, y todas las máquinas tienen un tiempo de usuario reducido para el comando, pero es posible que tenga un tiempo general más lento (y no tengo idea de por qué el suyo es tan dramáticamente más lento que mi Mountain Lion Mac).
11 pulgadas Air (i7) 2011 con Mountain Lion - SSD:
$ system_profiler SPSoftwareDataType
System Version: OS X 10.8.2 (or something)
Kernel Version: Darwin 12.3.0
Secure Virtual Memory: Enabled
$ time lsof /tmp/testfile
real 0m1.179s
user 0m0.012s
sys 0m1.158s
$ sudo dtruss lsof /tmp/testfile 2> /tmp/dump
$ cat /tmp/dump | sort | uniq -c | sort -nr | head
9310 proc_info(0x2, 0x68, 0x8) = 1272 0
1220 proc_info(0x2, 0xCEB6, 0x8) = 1272 0
$ cat /tmp/dump | cut -c -9 | sort | uniq -c | sort -nr | head
30884 proc_info
116 write(0x4
87 read(0x5,
60 sigaction
60 setitimer
35 stat64("/
30 sigprocma
30 sigaltsta
21 close(0x3
18 close(0x6
MacBook Pro de 15 pulgadas con Lion Server - HDD:
$ system_profiler SPSoftwareDataType
System Version: Mac OS X Server 10.7.5 (11G63)
Kernel Version: Darwin 11.4.2
$ time lsof /tmp/testfile
real 0m0.329s
user 0m0.005s
sys 0m0.324s
iMac de 27 pulgadas con Lion - HDD:
$ system_profiler SPSoftwareDataType
System Version: Mac OS X 10.7.5 (11G63b)
Kernel Version: Darwin 11.4.2
$ time lsof /tmp/testfile
real 0m0.066s
user 0m0.002s
sys 0m0.065s
$ sudo dtruss lsof /tmp/testfile 2> /tmp/dump
$ cat /tmp/dump | cut -c -9 | sort | uniq -c | sort -nr | head
23034 proc_info
188 write(0x4
141 read(0x5,
96 sigaction
96 setitimer
48 sigprocma
48 sigaltsta
31 stat64("/
21 close(0x3
18 close(0x6
Warren Peña
jason
lsof
sin argumentos (para enumerar todos los archivos), se cuelga durante un minuto y luego imprime todos los archivos. Pero, como mencioné, todavía se bloquea si trato de enumerar quién tiene un solo archivo abierto en el directorio /tmp, por lo que el problema no es un archivo abierto en particular. Además, no estoy ejecutando ningún proceso de AirServer.Lrí
sudo opensnoop -n lsof
.daviewales
jason
sudo opensnoop -n lsof
ylsof /tmp/testfile
en dos pestañas, y opensnoop solo informó que se habían abierto tres archivos. Entonces, el problema no debe ser un número excesivo de archivos abiertos, sino algo relacionado conproc_info
llamadas excesivas.bmike
lsof
es un segundo más lento en Mountain Lion que en Lion, por lo que claramente se está produciendo algún cambio (tal vez estén optimizando para otras llamadas o haciendo mucho más trabajo con GateKeeper o firma de código).willem hengeveld
Guruz
stuart woodward
JW.