1 votos

La mejor manera de mejorar el rendimiento del disco (SQL Server 2000)

Estoy teniendo algunos problemas de acceso al disco en una aplicación web.

La carga principal son muchas inserciones/actualizaciones/selecciones concurrentes en tablas grandes.

Actualmente es un único rackmount 2ru corriendo SQL Server 2000 e IIS, corriendo un raid5 con 4x15k SAS para la DB; y 6GB de ram/8 núcleos físicos. Los usos de la CPU y la memoria parecen estar bien.

Cosas que estoy considerando....

  • pasar de nuestro actual Raid a una SAN de muchos discos
  • Unidad Ram para archivos tempdb
  • Agrupar el servidor
  • Actualizar SQL-Server (lo hará en algún momento, pero las nuevas y útiles palabras clave deberían ser de gran ayuda, como mínimo)
  • ?

¿Hay algo que deba mirar/considerar?

Gracias, Chris

5voto

Some French Guy Puntos 96

Mueva sus datos y registros a un FusionIO disco, muy muy caro pero que yo sepa no se puede conseguir ahora mismo un almacenamiento persistente más rápido.

Ah, y deberías pasar a 2008R2 de 64 bits también, por supuesto, además de cargarte de memoria.

3voto

Hutch Puntos 1694

Lo primero que me viene a la mente es mirar de convertir ese RAID5 en un RAID10 o en un par de RAID1.

2voto

SQL3D Puntos 610

Un par de cosas. En primer lugar, la agrupación del servidor no le dará ningún beneficio de rendimiento, sólo el aumento de la disponibilidad.

Probablemente lo más fácil que puedes hacer para aliviar la E/S del disco es aumentar la memoria de tu servidor. A medida que más páginas de datos se almacenan en la RAM, menos E/S física tiene que ocurrir para que las consultas se ejecuten.

Dependiendo de su carga de trabajo, si usted puede permitirse el lujo de moverse a una SAN, entonces usted probablemente querrá mirar a la división de su TempDB, registros y archivos de datos en discos físicos separados (es posible que desee ver este artículo de MS en torno a las 10 mejores prácticas de almacenamiento para SQL Server: http://technet.microsoft.com/en-us/library/cc966534.aspx ). Como ha dicho Hutch, abandone el RAID 5, especialmente para los registros y TempDB, ya que estos tienen una gran cantidad de escrituras (el RAID 5 tiene una penalización de escritura para la paridad).

Como dice Chopper3, las unidades FusionIO son algunas de las más rápidas que existen actualmente. Si tienes el presupuesto para ello, es definitivamente un área a explorar (especialmente para tus TempDBs).

HTH, Dan

2voto

AndersNS Puntos 111

Es un tema muy amplio, pero quizá pueda ofrecerte algunos consejos para ayudarte a empezar. En general, creo que es seguro decir que usted tendrá que reunir información más precisa antes de que pueda decidir la mejor manera de atacar su problema. Al final probablemente se reducirá a un problema de memoria o de disco.

(Ignoraré la posibilidad de mirar las consultas que se ejecutan lentamente e intentar averiguar si hay formas de mejorarlas. Esta es una gran tema pero el uso del analizador de consultas puede ayudarle a determinar si le falta un índice o de una consulta debe ser completamente reescrita).

Yo empezaría por utilizar la Herramienta Administrativa de Rendimiento para ver algunas métricas clave. Los contadores de rendimiento de SQL Server son un buen lugar para mirar. Cola de discos Las estadísticas también pueden ser muy reveladoras. ¿Las aplicaciones (por ejemplo, SQL Server) están esperando la E/S del disco para realizar operaciones? Si es así, entonces sabes que necesitarás actualizar los discos (o arreglar las consultas, posiblemente). @Hutch tiene razón en que el RAID 10 ofrecerá un mejor rendimiento que el RAID 5 para un servidor de bases de datos, pero realmente eso sólo va a entrar en juego si estás esperando en las escrituras. 4 unidades de 15k RPM en un RAID 5 deberían ser capaces de manejar una carga bastante razonable con una tarjeta RAID decente (por supuesto lo que es razonable y/o decente es relativo).

También me gustaría comprobar la memoria . El servidor está ejecutando SQL Server 2000 por lo que voy a suponer que es un sistema operativo de servidor de 32 bits. ¿Es capaz el servidor SQL de utilizar toda esa memoria? En un sistema de 32 bits tendrá que utilizar PAE para utilizar los 6 GB, e incluso entonces creo que el propio proceso del servidor SQL sólo podrá crecer hasta 4 GB. Puedes usar un programa como el explorador de procesos de sysinternals para ver cuánta memoria se está usando realmente. Incluso puede ver cuánta memoria "quiere" SQL Server -- compruebe los contadores de SQL Server: Memory Manager counters (si están disponibles en el 2000, no lo recuerdo).

También mencionas que el servidor está ejecutando IIS. Si está ejecutando MS SQL Server en un servidor que también está ejecutando otros servicios muy cargados, es posible que desee configurar manualmente la cantidad de memoria que se debe utilizar. Por defecto, SQL Server asume que está en un servidor dedicado y trata de asignar dinámicamente tanta memoria como sea posible; dependiendo de las necesidades de sus procesos IIS esto puede no ser una buena cosa. En los servidores que ejecutan múltiples aplicaciones, normalmente me gusta configurar SQL Server para que utilice exactamente una determinada cantidad de RAM, estableciendo el mínimo y el máximo en el mismo valor (por ejemplo, 4GB, 10GB, lo que sea).

Por último, podría considerar la posibilidad de actualizar SQL Server. SQL Server 2005 introdujo algunas grandes mejoras de velocidad en determinadas áreas que podrían beneficiarle en función de su configuración. Por no mencionar el hecho de que puedes obtener una versión de 64 bits de SQL Server 2005/2008 y ejecutarla en un sistema operativo de 64 bits para darle aún más memoria, y la memoria es, con mucho, una de las cosas más importantes para un servidor SQL.

0voto

Joset Puntos 113

Este tema necesita un enorme "Depende" como respuesta. Aunque las respuestas publicadas hasta ahora son buenas y correctas para determinadas condiciones, hay mucho más.

Sí, pasar de RAID-5 a RAID-10 es una gran marca en la columna "Hazlo ahora", pero ¿qué pasa con las piezas que no nos han dicho?

Pensando en esto, se me ocurren los siguientes puntos: Disposición del disco:
¿Qué archivos están en qué unidades? ¿Dónde está la TempDb y cuántos archivos están asociados a la TempDb? ¿Están las DB's y los T-Logs en diferentes unidades?

Gestión y optimización de consultas:
¿Se han identificado y optimizado las consultas más pesadas? ¿Cómo? ¿Las actualizaciones causan reubicaciones de filas o son capaces de "Actualizar en el lugar"? Las reubicaciones de filas durante una actualización causan todo tipo de problemas de rendimiento. Gestión de índices: ¿Están los índices necesarios en su lugar y están correctamente definidos para ser utilizados por las consultas que los necesitan? Reconstrucción de índices: Los índices se fragmentan con el tiempo y necesitan ser reorganizados o reconstruidos. No no hacerlo afectará al rendimiento.

Entorno: La fragmentación de la unidad puede llevar a la fragmentación de los archivos. Incluso cuando la unidad se mantiene limpio, un gran número de extensiones para cualquier DB o archivo T-Log tiene un efecto negativo. Actualizar de SQL 2000 a SQL 2005 o (mejor aún) 2008 o 2008 R2 es una gran sugerencia. Ejecutar en Windows Server 2008 x64 o Windows Server 2008 R2 x64 complementa la 6GB de memoria en forma nativa. SQL Server 2008 y 2008 R2 tienen herramientas incorporadas para ayudar a identificar problemas consultas. En un entorno estresado con un DBA estresado, esto vale la pena la actualización. Memoria caché del controlador de la unidad: ¿Es suficiente? ¿Se comparte la caché entre varias unidades lógicas?

Competencia de recursos (presión):
Además de IIS, ¿qué otros procesos en el sistema de SQL Server están compitiendo por los recursos del sistema? recursos del sistema?

Añadir una SAN no es una mala idea, pero hay que entender el entorno. Es muy importante saber si la causa de los problemas de rendimiento se debe a los escaneos de tablas, a la gestión inadecuada de claves externas, a la reubicación de filas durante la actualización, a algún otro problema o a "todo lo anterior". Si no se conoce la causa subyacente, la adición de una SAN sólo será una ayuda temporal. Además, es obligatorio conocer el entorno para dimensionar correctamente una SAN, ya que no se trata sólo del espacio de disco disponible.

No conozco su entorno y no podría dar una respuesta razonable a lo que debe hacer; además, mi lista anterior es realmente la punta de un tema al que se han dedicado muchos libros reflexivos.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: