Hemos escrito una aplicación que realiza escrituras pequeñas (22 kB) en varios archivos a la vez (un subproceso realiza escrituras en cola asíncronas en varias ubicaciones en nombre de otros subprocesos) en el mismo volumen local (RAID1).
El 99,9% de las escrituras son de baja latencia, pero ocasionalmente (tal vez cada minuto o dos) obtenemos una o dos escrituras de latencia enorme (he visto 10 segundos o más) sin ninguna explicación real.
Plataforma: Servidor Win2003 con NTFS.
Monitoreo: Sysinternals Process Monitor (ver enlace a continuación) y nuestro propio registro de aplicaciones.
Hemos intentado varias cosas para intentar resolver este problema que se han obtenido de algunos sitios web, por ejemplo:
Hacer que la primera parte de los nombres de archivos sea única para ayudar a la generación de nombres 8.3
Escribir archivos en varios directorios
Cambiar el almacenamiento en caché de escritura en disco Intel
Compartir archivos/impresoras de Windows
Minimizar la memoria utilizada
Balance
Maximice el rendimiento de datos para compartir archivos
Maximice el rendimiento de datos para aplicaciones de red
Sistema->Avanzado->Rendimiento->Avanzado
NtfsDisableLastAccessUpdate: utilice el conjunto de comportamiento fsutil enablelastaccess 1
deshabilite la generación de nombres 8.3: use "fsutil conjunto de comportamiento deshabilitar8dot3 1" + reiniciar
Habilite un caché del sistema de archivos de gran tamaño
Deshabilitar la paginación del código del kernel
Límite de bloqueo de página IO
Desactivar (o activar) el servicio de indexación
Pero nada parece hacer mucha diferencia. Hay una gran cantidad de cosas que aún no hemos probado, pero nos preguntamos si alguien se había encontrado con el mismo problema, una razón y una solución (programática o no).
Podemos reproducir el problema usando IOMeter y una configuración simple:
Inicie IOMeter y elimine todos los subprocesos de trabajo excepto el primero en 'Topología' usando el botón de desconexión.
Seleccione el subproceso de trabajo y coloque una cruz en el cuadro junto al disco que desea usar en la pestaña Destinos de disco y coloque '2000000' en Tamaño máximo de disco (NOTA: debe tener al menos 1 GB de espacio libre; el tamaño del sector es 512 bytes)
A continuación, cree una nueva especificación de acceso y agréguela al hilo de trabajo:
Tamaño de la solicitud de transferencia = 22 kB
100% Secuencial
Porcentaje de especificación de acceso = 100%
Porcentaje de lectura/escritura = 100% escritura
Cambie la frecuencia de actualización de la pantalla de resultados a 5 segundos, el tiempo de ejecución de la configuración de la prueba a 20 segundos y ambas configuraciones de 'Número de trabajadores para generar automáticamente' a cero.
Seleccione el subproceso de trabajo en el panel Topología y presione el botón Duplicar trabajador 59 veces para crear 60 subprocesos con configuraciones idénticas.
Presione el botón 'Ir' (bandera verde) y controle la pestaña Resultados. El 'Tiempo máximo de respuesta de E/S (ms)' siempre llega al menos a 3500 en nuestra máquina. Nuestra máquina no es exactamente lenta (servidor en rack Xeon de 8 núcleos con 4 GB y RAID integrado).
Me interesaría ver qué obtienen otras personas. Tenemos la sensación de que podría tener algo que ver con el sistema de archivos NTFS (el nuestro está actualmente lleno en un 75% de archivos fragmentados) y vamos a probar algunas cosas en torno a este principio. Pero también está relacionado con el rendimiento del disco, ya que no lo vemos en un disco RAM y no es tan grave en una matriz RAID10.
Cualquier ayuda es muy apreciada.
Ricardo
Haga clic derecho y seleccione 'Abrir enlace en una pestaña nueva':
Resultado del proceso
Respuesta1
Ahora tengo más información sobre este tema.
Habiendo probado la prueba IOMeter descrita en 12 máquinas diferentes usando una variedad de hardware, la he reducido a un chipset RAID específico (3 máquinas diferentes con el mismo chipset exhiben este comportamiento usando RAID1 y RAID10). Todas las demás máquinas obtienen resultados al menos un orden de magnitud mejores.
Conjunto de chips: Intel 631xESB/632xESB SATA RAID (también conocido como ESB2)
Consulte esta publicación en el sitio de Intel para obtener más información y, con suerte, una respuesta de Intel:
Intel 631xESB/632xESB SATA RAID (también conocido como ESB2) escribe lento
Ricardo