2011-12-09 12 views
7

Tengo una aplicación C (VStudio 2010, win7 64bit) que se ejecuta en una máquina con chips dobles xeon, lo que significa 12 núcleos físicos y 24 lógicos, y 192 gigas de ram. EDITAR: EL SO es win7 (es decir, Windows 7, 64 bit).Optimización de escrituras masivas en el disco

La aplicación tiene 24 hilos (cada hilo tiene su propio núcleo lógico) haciendo cálculos y llenando una parte diferente de una estructura C masiva. La estructura, cuando todos los hilos están terminados (y los hilos están perfectamente equilibrados para que se completen al mismo tiempo), es de aproximadamente 60 gigabytes.

(Tengo control sobre la configuración del hardware, así que voy a usar 6 unidades de 2tb con RAID 0, lo que significa que los límites físicos de escritura serán aproximadamente 6x la velocidad de escritura secuencial promedio, o aproximadamente 2 gig/second .)

¿Cuál es la forma más eficiente de obtener esto en el disco? Obviamente, el tiempo de E/S empequeñecerá el tiempo de cómputo. De mi investigación sobre este tema, parece que escribir() (en lugar de fwrite()) es el camino a seguir. Pero, ¿qué otras optimizaciones puedo hacer por el lado del software, en términos de establecer tamaños de búfer, etc. ¿Sería mmap más eficiente?

+0

Agregue una etiqueta en qué idioma desea escribir. Esto ayuda a que otros encuentren esta pregunta fácilmente. – Buddha

+0

¿Cuánto tiempo tarda el cálculo? –

+0

Veo una etiqueta 'mmap'. ¿Está disponible para tu sistema? –

Respuesta

6

Es difícil juzgar lo mejor para su situación.

La primera optimización para hacer es preasignar el archivo. De esta forma, su sistema de archivos no necesita seguir ampliando su tamaño. Eso debería optimizar algunas operaciones de disco. Sin embargo, evite escribir ceros reales en el disco. Solo establece la longitud.

Luego tiene opciones entre mmap y write. Esto también depende del sistema operativo que use. En un Unix probaría tanto mmap como pwrite. pwrite es útil porque cada uno de tus subprocesos puede escribir en el archivo en la posición de archivo deseada sin pelear por los desplazamientos de archivos.

mmap podría ser bueno porque en lugar de hacer copias en el caché de archivos, sus hilos estarían escribiendo directamente en el caché de archivos. 60 GB es probablemente demasiado grande para mmap el archivo completo, por lo que cada hilo probablemente necesitará su propia ventana de mmap en el archivo que se puede mover.

En Windows, es probable que desee probar el IO asincrónico superpuesto. Eso solo se puede hacer con llamadas API de Win32.

+1

Windows tiene el equivalente de mmap (CreateFileMapping, MapViewOfFile), y es probable que sea bueno por las mismas razones que Zan enumerado. –

+1

Y por las mismas razones (es lo que usa el sistema operativo) los archivos asignados también tienen un buen rendimiento en Windows. Plus windows puede mapear un archivo en una unidad de red. Unix no solía ser capaz de hacer mmap sobre nfs - ¿Ha cambiado eso? –

8

mmap(), o boost mmap es casi siempre el mejor enfoque. El sistema operativo es más inteligente que tú, ¡deja que se preocupe por lo que almacenar en caché!

Usted no dijo qué sistema operativo, pero en Linux el madvise, o sugerencias de impulso equivalentes realmente pueden aumentar el rendimiento.

+1

+1, siempre, ¡siempre deja que otra persona sude la mayor cantidad de detalles posible! –

Cuestiones relacionadas