El cliente está experimentando un rendimiento deficiente de Sybase ASE 15 en una SAN PS6000X con 16 X 450 GB 10 K en RAID-50. El servidor es un Dell R710 que ejecuta el servidor 2003 R2 de 64 bits en ESX 4.0.0,256968
He usado sqlio para comparar el rendimiento de escritura secuencial de bloques de 4 KB en la unidad.
sqlio -kW -t1 -s600 -dE -o1 -fsequential -b4 -BH -LS sqliotestfile.dat
El resultado es 1900 IOPS. Sin embargo, cuando Sybase ejecuta una carga de trabajo sostenida de pequeñas inserciones, SAN HQ muestra 590 IOPS consistentes (y una actividad de escritura de 100 % de 4K). También muestra que la latencia de escritura aumenta de <1 ms a 1,2 ms.
El monitoreo y las pruebas en Sybase demuestran que el problema de rendimiento está relacionado con IO y, en particular, hay mucho tiempo de espera para escribir en el registro.
La SAN indica que el almacenamiento en caché de escritura está habilitado.
¿De qué IOPS debería ser capaz la SAN para una actividad de escritura secuencial de 4k? Además, con el almacenamiento en caché de escritura habilitado, ¿no debería el controlador agrupar las escrituras 4K en algo más eficiente?
Además, se agradecería cualquier consejo sobre Sybase en ESX.
Respuesta1
Esperaría que la E/S secuencial fuera más rápida de lo que está viendo, pero la E/S de escritura aleatoria 100 % sostenida de 4K sería de alrededor de 500-600 IOPS para esa configuración [suponiendo 14 discos activos, 10 K SAS, RAID 50], por lo que la pregunta que haría La pregunta es ¿cómo está seguro de que el patrón IO en el volumen es realmente secuencial?
Qué otros volúmenes presenta la PS600X y para qué se utilizan. Los arreglos Equallogic realmente no le permiten aislar patrones de IO entre volúmenes en el mismo arreglo y si tiene otro volumen o volúmenes extraídos de los mismos discos que están experimentando tráfico de IO aleatorio, eso podría estar causando esto.
Respuesta2
Lo primero es lo primero: ¿el tamaño del archivo de prueba es comparable al de la base de datos real? Si no, los tiempos de búsqueda pueden serel factor diferenciadoraquí.
Si aún no está utilizando el adaptador scsi paravirtual vmware para el volumen de registro, le recomiendo que lo pruebe. No es una solución mágica, pero ciertas cargas de trabajo se benefician de ella. Por lo general, agrega un poco de latencia, pero permite un mayor rendimiento general cuando se trata de una gran cantidad de escrituras.
Si es factible, y me doy cuenta de que es una gran molestia, es posible que desee considerar la posibilidad de conectar una instancia física de este mismo servidor directamente a la SAN y ejecutar la misma prueba, eliminando a ESX de la ecuación. Dado que está leyendo las cifras de IOPS de dos ubicaciones y productos separados, también lo consideraría un posible factor. Dicho esto, no esperaría que las cifras se tripliquen.