¿Por qué una aplicación con uso intensivo de disco se ejecuta más rápido en una SAN que en un disco físico?

21

¿Por qué una aplicación con uso intensivo de disco se ejecuta más rápido en una SAN que en un disco físico? Hubiera esperado que el disco físico fuera un poco más rápido, pero de hecho el proceso se ejecutó 100 veces más rápido cuando su unidad de trabajo se configuró en una partición en la SAN.

Suponemos que la SAN está optimizada de forma inmediata para que sea rápida, mientras que la configuración de ajuste del disco físico está relacionada con el sistema operativo (Solaris) y no se ha tocado ni se ha parcheado el sistema operativo.

Durante la actividad más alta, la E / S del disco se estaba ejecutando al 100% y el tiempo para completar una escritura fue de más de 2 segundos, ya que varios procesos escribían en el disco al mismo tiempo.

(Para su información, la aplicación involucrada fue Informatica PowerCenter)

performance storage-area-network hard-drive tuning Stuart Woodward
fuente

Respuestas:

23

No estoy para nada sorprendido. Las matrices SAN generalmente tienen MUCHOS discos involucrados. El factor limitante para la E / S de disco es la velocidad del disco individual, y estos se apilan. 6 unidades localmente en un RAID10 funcionarán mejor que 2, y 80 unidades en una SAN funcionarán mejor que 10 unidades localmente. Hay variables, por supuesto, pero así es como se supone que debe funcionar.

Además, si la SAN tiene algún SSD involucrado, las cosas se ponen realmente rápidas.

sysadmin1138
fuente
15

Es casi seguro que se debe al almacenamiento en caché. El DAS probablemente tiene un almacenamiento en caché mínimo, donde la mayoría de las SAN empresariales tienen varios gigabytes de caché. Supongo que la aplicación está saturando la memoria caché del DAS, pero no la SAN.

Chris S
fuente
1
La latencia obvia en la SAN es más larga que la DAS, pero el rendimiento general es mayor en la SAN con todo su almacenamiento en caché. Buena respuesta.
Matt
y luego a menudo hay un caché de lectura anticipada, por lo que sus lecturas / escrituras aleatorias son las que reciben el mayor golpe y luego puede escribir en caché de manera que sus únicas lecturas aleatorias se vean afectadas, aunque todavía es un retraso bastante pequeño.
Silverfire
1
Un subsistema de almacenamiento configurado correctamente en la SAN que no esté sobrecargado debería proporcionarle tiempos de escritura aleatorios de alrededor de 1-2 ms.
MikeyB
@MikeyB No estoy en desacuerdo contigo. 1-2ms escribir en SAN parece correcto. Pero la configuración SAN de Charles fue 100 veces más rápida que sus discos físicos sobrecargados (las escrituras fueron> 2 segundos para este último). Entonces, ¿incluso su rendimiento SAN no es tan bueno, a 20 ms en lugar de 1-2 ms ...?
Ellie Kesselman
9

Conceptualmente, siempre parece que servir discos desde SAN debería ser más lento que servirlo localmente. Sin embargo, hay muchos factores que pueden revertir esto y dar como resultado que la SAN sea una opción mucho más rápida. Algunos de estos factores son:

  • ¿Su carga de trabajo requiere un tiempo de búsqueda rápido o un rendimiento rápido, o ambos?
  • ¿Cuántos husos en el SAN LUN frente al disco local?
  • ¿Qué velocidad de bus entre SAN LUN y el servidor, en comparación con la interfaz del disco local?
  • ¿Cuánta caché de lectura / escritura está disponible en SAN LUN frente al disco local?
  • ¿A qué velocidad giran los discos en SAN LUN frente al disco local?
  • ¿Qué otra actividad de IO está teniendo lugar en el SAN LUN frente al disco local?
  • ¿Qué nivel de RAID son las matrices en la SAN y el almacenamiento local?

Todo esto afectará su rendimiento en SAN y disco local.

Chris Thorpe
fuente
1

Todo se reduce a la cantidad de cabezales disponibles ... Cuanto mayor sea la cantidad de cabezales, más rápido será acceder a cualquier dato dado. si es muy intensivo en IO, especialmente si es una aplicación de base de datos, puede enterrar fácilmente el rendimiento del disco local con una solución SAN que puede tener un número mucho mayor de conjuntos de discos para la gestión de datos, índices y demás.

Con el subsistema de disco local, también es probable que comparta el acceso a los cabezales de lectura / escritura con otras operaciones, como r / w para intercambiar, sistema operativo local y acceso a archivos de biblioteca, acceso a aplicaciones, etc. Mientras es individualmente rápido, el tiempo colectivo para todas las acciones de lectura / escritura para mover los cabezales de lectura / escritura de un área del disco para cubrir un conjunto de acciones a otro para satisfacer los requisitos de su aplicación, sin duda puede afectar el rendimiento.

James Pulley
fuente