¿Qué hace grep cuando no está ejecutando la CPU?

Cuando busco coincidencias grep, a menudo noto que la búsqueda posterior lleva mucho menos tiempo que la primera, por ejemplo, 25s vs. 2s. Obviamente, no es mediante la reutilización de las estructuras de datos de su última ejecución, deberían haberse desasignado. Al ejecutar un timecomando grep, noté un fenómeno interesante:

real    24m36.561s
user    1m20.080s
sys     0m7.230s

¿A dónde va el resto del tiempo? ¿Hay algo que pueda hacer para que funcione siempre rápido? (por ejemplo, hacer que otro proceso lea los archivos, antes de grepbuscarlos).

grep performance

— Alex
fuente

Respuestas:

A menudo está relacionado con el caché de la página .

La primera vez, los datos deben leerse (físicamente) del disco.

La segunda vez (para archivos no demasiado grandes) es probable que esté en la memoria caché de la página.

Entonces, podría emitir primero un comando como cat (1) para llevar el archivo (no demasiado grande) al caché de la página (es decir, en la RAM), luego un segundo grep (1) (o cualquier programa que lea el archivo) generalmente se ejecutará más rápido .

^{(sin embargo, los datos aún deben leerse desde el disco en algún momento)}

Consulte también (a veces útil en sus programas de aplicación, pero prácticamente raramente) readahead (2) y posix_fadvise (2) y quizás madvise (2) y sync (2) y fsync (2), etc.

Lea también LinuxAteMyRAM .

Por cierto, esta es la razón por la que se recomienda, al comparar un programa, ejecutarlo varias veces. Además, esta es la razón por la cual podría ser útil comprar más RAM (incluso si no ejecuta programas que lo usan todo para sus datos).

Si desea comprender más, lea un libro como, por ejemplo , Sistemas operativos: tres piezas fáciles

— Basile Starynkevitch
fuente

Entonces, la TL;DRrespuesta es "[bloque esperando] E / S".

— mgarciaisaia

@PaulDraper No realmente :) cat+ greptodavía va a tomar más tiempo que grepsolo.

— chepner

@chepner A menos que pueda realizar múltiples subprocesos y utilizarlos catcomo una búsqueda previa barata mientras está haciendo otra cosa, en preparación para el grepinterés.

— hBy2Py

@ MarkKCowan: ¡Gatos encantadores! :-) ⁠

— G-Man dice 'reinstalar a Monica' el

@ G-Man: También puedes reemplazar dos de las cats tacpor el mismo efecto y mayor uso de RAM: D O todos los gatos con tac

— Mark K Cowan

-1

En un entorno de almacenamiento en red, también puede haber retrasos relativamente significativos cuando accede por primera vez a un archivo que reside en un "archivador" separado del servidor. Una vez que se haya accedido a ese archivo en el servidor, se almacenará en caché localmente y el acceso posterior a los datos será mucho más rápido.

Aquí hay un experimento que solo calcula una suma de verificación de los datos del archivo, no grep. La primera invocación es lenta, y las posteriores son rápidas.

> du -Dh file_348m
348M    file_348m

> /usr/bin/time md5sum file_348m
738709b181b52ddfcef3413997f91462  file_348m
0.60user 0.15system 0:03.02elapsed 25%CPU (0avgtext+0avgdata 1524maxresident)k
708144inputs+0outputs (0major+80minor)pagefaults 0swaps

> /usr/bin/time md5sum file_348m
738709b181b52ddfcef3413997f91462  file_348m
0.67user 0.06system 0:00.73elapsed 99%CPU (0avgtext+0avgdata 1524maxresident)k
0inputs+0outputs (0major+80minor)pagefaults 0swaps

> /usr/bin/time md5sum file_348m
738709b181b52ddfcef3413997f91462  file_348m
0.65user 0.07system 0:00.73elapsed 99%CPU (0avgtext+0avgdata 1524maxresident)k
0inputs+0outputs (0major+80minor)pagefaults 0swaps

> /usr/bin/time md5sum file_348m
738709b181b52ddfcef3413997f91462  file_348m
0.66user 0.06system 0:00.73elapsed 99%CPU (0avgtext+0avgdata 1524maxresident)k
0inputs+0outputs (0major+80minor)pagefaults 0swaps

— Winston Smith
fuente

Agradecería comentarios para downvote (s), ya que no sé cómo interpretarlos. Creo que la descripción de mi respuesta es correcta. ¿Quizás el ejemplo de comando no está claro? ¿O no te gusta que no haya comparado el comando grep? (Intencionalmente usé un comando más simple, md5sum, para tratar de ilustrar mi punto.)

— Winston Smith

Creo que la razón es que su publicación no agregó ninguna información nueva relevante a lo que estaba preguntando. Ya sabía que había un retraso, y la primera respuesta ya explicaba por qué está sucediendo. Pero sí, recibo votos negativos sin explicación también. Incluso en preguntas con buenas respuestas.

— Alex

Gracias @Alex por sugerir una razón. Intenté distinguir entre el tiempo de sobrecarga para mover datos del almacenamiento local a la memoria, que se describe en la primera respuesta, y el tiempo de sobrecarga para mover datos del almacenamiento de red al servidor local. Pensaré si pudiera describir esto más claramente o proporcionar mejores ejemplos de comandos.

— Winston Smith

Supongo que después de leer su publicación, mi pensamiento es que sigue siendo la sobrecarga de mover datos desde cualquier lugar donde estén almacenados, a la memoria. Ya sea desde el almacenamiento en red o desde el almacenamiento local, no importa: Unix todavía lo ve como moverse de un directorio a la memoria. ps-- parece que mi explicación es correcta-- mi comentario con la razón recibió un voto positivo.

— Alex

Ya veo, estaba agregando una distinción que no es importante para lo que estabas buscando. OKAY. Por cierto, he votado a favor de tu comentario, por lo que no resuelve la cuestión del motivo del voto negativo. :-)

— Winston Smith