¿Cómo puedo perfilar la E/S del archivo?

Question

Nuestra construcción es molestamente lenta. Es un sistema Java construido con Ant, y estoy ejecutando el mío en Windows XP. Dependiendo del hardware, puede tardar entre 5 y 15 minutos en completarse.

Ver las métricas de rendimiento general en la máquina, así como las diferencias de hardware correlacionadas con los tiempos de compilación, indica que el proceso está vinculado a E/S. También muestra que el proceso lee mucho más que escribir.

Sin embargo, no he encontrado una buena manera de determinar qué archivos se están leyendo o escribiendo, y cuántas veces. Mi sospecha es que con nuestros muchos subproyectos e invocaciones subsecuentes del compilador, la construcción vuelve a leer las mismas bibliotecas comúnmente usadas muchas veces.

¿Cuáles son algunas herramientas de creación de perfiles que me dirán qué proceso determinado está haciendo con qué archivos? Gratis es agradable, pero no esencial.

---

Usando Process Monitor, as suggested by Jon Skeet, pude confirmar mi sospecha: casi toda la actividad del disco fue la lectura y relectura de las bibliotecas, con las copias de "rt.jar" y otras bibliotecas del JDK en la parte superior de la lista. No puedo crear un disco RAM lo suficientemente grande como para albergar todas las bibliotecas que utilicé, pero montar las bibliotecas "más populares" en un disco RAM reduce los tiempos de compilación en un 40%; claramente, el almacenamiento en caché del sistema de archivos de Windows no está haciendo un trabajo lo suficientemente bueno, a pesar de que le he dicho a Windows que optimice para eso.

Una cosa interesante que noté es que la operación típica de 'lectura' en un archivo JAR es solo una docena de bytes; generalmente hay dos o tres de estos, seguidos por un salto de varios kilobytes más adelante en el archivo. Parecía ser inadecuado para lecturas masivas.

Voy a hacer más pruebas con todos de mis bibliotecas de terceros en una unidad flash, y ver qué efecto tiene.

Answer 1

Si solo lo necesita para Windows, SysInternals Process Monitor debería mostrarle todo lo que necesita saber. Puede seleccionar el proceso, luego ver cada operación como va y obtener un resumen de la operación del archivo también.

Answer 2

Solía ​​construir una aplicación Java masiva (interfaz JSP) usando Ant en Windows y tomaría más de 3 minutos. Limpié mi computadora e instalé Linux, y de repente las construcciones tomaron 18 segundos. Esos son números reales, aunque tienen alrededor de 3 años. Solo puedo suponer que Java prefiere la gestión de memoria de Linux y los modelos de subprocesamiento a los equivalentes de Windows, ya que todos los programas de Java parecen funcionar mejor bajo Linux en mi experiencia (especialmente Eclipse). Linux parece mucho mejor para evitar lecturas extra del disco cuando lee un montón de archivos que no han cambiado (es decir, archivos ejecutables y bibliotecas). Esto puede ser una propiedad de la memoria caché de disco o del sistema de archivos, no estoy seguro de cuál.

Una de las mejores cosas de Java es que es multiplataforma, por lo que la configuración de un servidor de compilación basado en Linux es en realidad una opción para usted. Al ser algo así como un evangelista de Linux, preferiría que cambies tu entorno de desarrollo a Linux, pero sé que muchas personas no quieren hacerlo (o no pueden hacerlo por razones prácticas).

Si no está dispuesto siquiera a configurar un servidor de compilación de Linux para ver si se ejecuta más rápido, al menos podría intentar desfragmentar el disco duro de su máquina de Windows. Eso hace una gran diferencia para las compilaciones de C++ en mi computadora de trabajo. Pruebe JkDefrag, que parece mucho mejor que el desfragmentador que viene con Windows.

EDIT: Supongo que obtuve un voto negativo porque mi respuesta no aborda la pregunta exacta. Sin embargo, es una tradición de StackOverflow ayudar a las personas a resolver su problema real, no solo tratar los síntomas. No soy una de esas personas para quienes la respuesta a cada pregunta es "use linux". En este caso, sin embargo, tengo ganancias de rendimiento muy reales y medidas en exactamente la situación que el OP está preguntando, así que pensé que valía la pena compartir mis experiencias.

Answer 3

Cuando aún usaba Windows solía obtener buenos resultados acelerando mi compilación haciendo que todos los resultados de compilación se escriban en una partición separada, tal vez 3   GB, y formateando periódicamente eso en la noche una vez por semana a través de un programa tarea. Es solo producción de compilación, por lo que no importa si se aplasta unilateral de vez en cuando.

Pero, sinceramente, desde que me mudé a Linux, la fragmentación del disco es algo de lo que ya no me preocupo más.

Otra razón para probar su acumulación en Linux, al menos una vez, es por lo que se puede ejecutar strace (grepped para llamadas a abierta) para ver qué archivos de su construcción es el tacto.

Answer 4

Un viejo pero bueno: crea un disco RAM y compila tus archivos desde allí.

Answer 5

En realidad, FileMon es una herramienta más directa que ProcMon. En general, cuando se ejecuta el análisis de rendimiento de disco E/S, considere los dos siguientes:

• Rendimiento (velocidad de lectura/escritura de bytes por segundo)
• Latencia (cuánto en espera en la cola para la lectura/escritura)

Una vez que evalúa el rendimiento del sistema en términos de lo anterior, es fácil identificar el cuello de botella y tomar medidas correctivas: obtener discos más rápidos o cambio del código (el que sale más barato).