Acceso al disco de generación de perfiles

Question

Actualmente estoy trabajando en una aplicación MFC que lee y escribe en el disco. A veces, esta aplicación funciona increíblemente rápido y, a veces es muy lento. Supongo que es por el acceso al disco involucrado, por lo tanto, quiero perfilarlo. Estas son algunas preguntas al respecto:

(1) .Actualmente uso AQTime profiler para perfilar la aplicación. ¿Alguien ha tratado de perfilar el acceso al disco usando esto? o hay alguna otra herramienta disponible que pueda usar?

(2). ¿Cuáles son los parámetros de disco más importantes que debería mirar?

(3). Si tengo varios hilos tratando de leer y escribir los datos del disco, ¿afecta el rendimiento? es decir, ¿es mejor tener un solo acceso con hebra al disco?

Answer 1

Puede usar el Windows Performance Toolkit para esto. Puede habilitar proveedores de seguimiento para eventos de E/S de disco y ver el tiempo de E/S y el tiempo de servicio de disco para cada uno. Sin embargo, tiene un poco de una curva de aprendizaje. Esto también le permitirá determinar qué archivos de E/S realmente dan como resultado un acceso real al disco y no son manejados por el administrador de caché.

Los parámetros más importantes son el tiempo de servicio del disco y la longitud de la cola. El tiempo de servicio de disco es cuánto tiempo el disco realmente tomó para atender la solicitud. La longitud de la cola indica si su solicitud de disco está respaldada por otras solicitudes.

Para muchos hilos w/lee & escribe - Muchos discos tienen un rendimiento deficiente frente a lecturas con escrituras de fondo. Si tiene varios hilos haciendo muchas E/S de disco en ubicaciones aleatorias en el disco, puede terminar muriendo de hambre con ciertas solicitudes.

Answer 2

para ayudarle con (2):

1. Tratar de lotes de seguridad de sus escrituras en disco para evitar muchas pequeñas llamadas a escribir. Cuando termines de descargar tu búfer, llama a commit. commit (también conocido como fsync) es una operación costosa, por lo que se vuelve aún más cuando hay muchas escrituras pequeñas.
2. En los identificadores de archivos de Windows puede experimentar con FILE FLAG WRITE THROUGH para aumentar las velocidades de escritura. Supuestamente commit no tiene que ser llamado con identificadores usando esta bandera.
3. Si también se accederá a los datos que está escribiendo en el disco mediante lectura, considere escribir primero en una estructura de memoria, tener otra secuencia de lectura de la estructura para escribirla en el disco. Esto ayudará a evitar llamadas para leer datos del disco que acaba de escribir.

Esperemos que esto ayuda ....

Answer 3

Lo que yo haría es, si no se puede hacer una pausa en todos los temas al mismo tiempo y examinar su estado, se centran en uno de ellos y la pausa que, aunque está siendo "malditamente lento". This is a little known but effective technique.

Dado que es extremadamente lento en comparación con lo que podría ser, lo que sea que esté esperando lo está esperando probablemente el 99% del tiempo, por lo que cuando lo detenga lo verá. Eso es cierto ya sea una gran espera o un trillón de pequeños. Mira toda la pila de llamadas. El culpable puede estar en algún lugar en el medio de la pila.

Si no está seguro, pause dos o tres veces. El culpable estará en todas las muestras de la pila.