El artículo se divide en 3 posts:
- Parte 1: Optimización de los servidores de SQL Server (acá estamos)
- Parte 2: Optimización de la instancia de SQL Server
- Parte 3: Mantenimiento de SQL Server
OPTIMIZACION DE LOS SERVIDORES DE SQL SERVER
- El servidor de SQL Server debe estar dedicado para Sharepoint, no compartas el servidor con otras apps.
- Page file: dejar el valor default que viene con Windows Server 2012 (Automatic manage paging file size for all drives), ya que el mismo administra mejor la memoria. Para WS2008 es recomendable 1.5 x RAM disponible.
- Networking: 1 GB network interface card. En el caso que tengas problemas de performance con el tráfico de red, puede utilizar dos placas de red para los WFE/App Server, una para el servicio con los usuarios y la otra para el procesamiento (requiere configuración adicional, lo cual complica el mantenimiento). Revisar los contadores \Network Interface(*)\Output Queue Length (>1: revisar) y \Network Interface(*)\Current Bandwidth (>80%: revisar)
- Policy Lock Pages in memory: se recomienda agregar la cuenta de servicio de SQL Server a la policy. Es importante setear Max Memory correctamente y deshabilitar Balloon Drive (ver más abajo). Si hay dos instancias o otras apps corriendo en el servidor, se recomienda no utilizar esta policy, ya que puede afectar la performance
- Particiones: todas las particiones (volumes) deben estar formateadas con 64KB de allocation unit size. MUY IMPORTANTE este punto, notarás una gran diferencia de performance..
Format <drive> /Q /FS:NTFS /A:64K /V:Volume /Y
Dependiendo de la estimación del espacio requerido, y teniendo en cuenta que los servidores SQL serán virtualizados con VMware, se recomienda la siguiente distribución de discos, en donde:
El disco C: es para el sistema operativo.
El disco D: es para los binarios de SQL y para las apps
El disco E: es para los archivos MDF de las bases de datos (datafiles).
El disco F (High Range): es para la TempDB.
El disco G: es para los archivos LDF de las bases de datos (logs).
Los discos H: en adelante también son para los archivos MDF de las bases de datos, los mismos serán mid-range.
El disco C albergará los binarios del sistema operativo, dumps, page file, service packs, hotfixes, logs, etc.
* La suma total de los VMDKs (NTFS 64KB block size) podría disponibilizarse en un único VMSF
* * Los VMDKs (NTFS 64KB block size) se deberán disponibilizar sobre otro volumen VMSF (LUN diferente)
* * * La suma total de los VMDKs (NTFS 64KB block size) podría disponibilizarse en un único VMSF
- VMware (sólo mostraré para VMWare, para hyper-v son similares):
- Alinear los VMDK file ,VMFS volume y SAN LUN: Descripción detallada
- Direct path I/O: permite acceder a la Phisical NIC en vez de una vNIC. Se recomienda probar en ambientes de DEV antes de implementarlo en PRD; se pierden algunos features de VMware. Más información
- Adaptadores en formato VMXNet3
- Deshabilitar la feature Balloon Drive para la VM donde reside el SQL Server.
- Al provisionar la VM se recomienda utilizar el método Thick Provision Eager Zeroed.
- 1:1 ratio de phisical cores a virtual cores
- Se recomienda procesadores con alto cache L2 y L3.
- En el caso de alto throughput de networking, se recomienda utilizar NIC teaming. Más información
- RAID recomendaciones:
Vas a notar una gran mejora si pones la tempdb en un RAID 10 (SAS 15.000 RPM, 210 IOPS), otra posibilidad es usar SSD (discos de estado sólido)
- PowerPlan: High Performance. NO utilizar BIOS power saving feature.
- Performance Appearance: adjust for the best performance
- Procesor Scheduling: Best Performance of Background Services
- Deshabilitar la feature 8.3 Naming
- Tener en todas las particiones un 25% de espacio disponible para futuros crecimientos (rebuild de indices, crecimiento innesperado)
- Excluir del antivirus los paths y extensiones definidos en el siguiente link
- Cant de Cores y memoria del servidor: cada configuración dependerá de la cantidad de usuarios y documentación a guardar en el servidor, pero les dejo unas recomendaciones:
CORES
>10 gb <=1 TB de datos: 4 cores (1000 usuarios concurrentes)
>1TB de datos: 8 cores (10.000 usuarios concurrentes)
RAM
<1TB de datos: 16 GB
>1TB a 2 TB: 32 GB
>2TB a 5TB: 64 GB
>5TB a 16 TB: >64 GB
IMPORTANTE: esta configuración depende mucho del acceso a la información (porcentaje de reads, writes, etc), del procesamiento de la misma (workflows, BI, etc) y del tipo de información (records center, listas largas, etc)
- Antes de iniciar la instalación de SQL Server, evalua la performance de I/O del storage. Puedes utilizar SQLIO, IOMETER y CrystalDiskMark. Hay muchos ejemplos en internet de sus usos.
- Contadores útiles para tener en cuenta en servidores de SQL Server (relacionados a WS2012, más abajo describiré los relacionados a SQL Server):
· \LogicalDisk(*)\Avg. Disk sec/Read (es el tiempo promedio, en segundos de una lectura de datos al disco):
>12ms: respuesta lenta
>25ms: respuesta muy lenta
· \PhysicalDisk(*)\Avg. Disk sec/Read:
<10 ms: muy bueno
>10ms y 20ms: delay
>20ms y 50ms: lento, evaluar
>50ms: indica un problema grave I/O.
· \LogicalDisk(*)\Avg. Disk sec/Write (es el tiempo promedio, en segundos de una escritura de datos al disco):
>15ms: respuesta lenta
>25ms: respuesta muy lenta
· \PhysicalDisk(*)\Avg. Disk sec/Write: se utiliza los mismos threshold que \LogicalDisk(*)\Avg. Disk sec/Write
· \LogicalDisk(*)\Disk Transfers/sec (es la tasa de lectura y escritura en el disco):
<80 I/O por segundo en promedio cuando la latencia es mayor que 25ms, indica demasiadas virtual LUNs usando el mismo disco físico de una SAN.
· \Physical Disk\%Disk Time: representa el porcentaje de tiempo transcurrido que el disco está ocupado ofreciendo servicio de read y write.
>70%: evaluar I/O (incluir en la evaluación el contador de queue I/O)
· \Physical Disk\%Idle Time: mide cuando tiempo el disco permance en un estado idle.
<40%: evaluar discos. Ya que está teniendo mucho procesamiento.
· \Physical Disk\PhysicalDisk\ Current Disk Queue Length:
> (Nº de discos + 2): evaluar con PhysicalDisk\ Avg. Disk Queue Length
· \Process(*)\IO Data Operations/sec (La tasa actual en el cual el proceso emite operaciones de I/O de lectura y escritura, este contado cuenta la actividad de I/O generada por el proceso,incluye file´s, network y device I/Os):
Revisar si el proceso usa más de 1000 I/Os por segundo.
· \PagingFile\%Usage: describe la cantidad de uso del page file.
>90% indica un problema
· \Memory\Available MBytes (Available MBytes es la cantidad de memoria física en MB disponible para procesos ejecutandose en el servidor, este contado sólo indica el último valor y no un promedio ):
Bajo en memoria: menor a 10%
Muy bajo en memoria: menor a 5%
Fluctuaciones de 100MB por hora, esto indica un memory leak.
· \Memory\Pages/sec (si es alto, indica que el sistema se está quedando sin memoria y está tratando de paginar la memoria a disco, es la tasa de páginas que son leídas o escritas a disco. Este contador es un indicador primario de retrasos en el sistema. Picos en pages/sec son normales en backups, lectura de archivos de gran de tamaño:
Si es mayor a 20 pages/sec,se debería revisar
· \Memory\Free System Page Table Entries (es el número de entradas de la tabla de páginas no está en que utiliza el sistema. Este análisis determina si el sistema se está quedando sin entradas libres de la tabla de páginas del sistema (PTE))
Menor que 10,000: posiblemente tenga problemas de performance.
· Processor\% Processor Time (es el indicador principal de la actividad del processor activity, altos valores no siempren indican un problemasi se incrementan de forma lineal otros contadores tales como % Privileged Time o Processor Queue Length, se deberá revisar):
<50% consumido: OK
>50 y <90%: monitorear
>90 y <=100%: crítico
· \Processor\% Privileged Time:
Consistentemente sobre 75% indica un bottleneck.
· \System\Context Switches/sec (Context switching ocurre cuando un thread de mayor prioridad se antepone a un hilthreado de menor prioridad que se está ejecutando. Alto niveles de context switching pueden ocurrir cuando hay muchos threads que tienen el mismo nivel de prioridad. Esto indica que hay demasiados threads compitiendo por el tiempo del procesador:
· \Processor(*)\% Interrupt Time (Este contador indica el porcentaje de tiempo que el procesador invierte la recepción y el servicio de las interrupciones de hardware. Este valor es un indicador indirecto de la actividad de los dispositivos que generan interrupciones, tales como adaptadores de red. Un aumento dramático en este contador indica posibles problemas de hardware)
High CPU Interrupt Time: >30% indica algún problema de HW
· System\Processor Queue Length (Si hay más tareas listas para ejecutarse que procesadores existentes, los threads se encolan. La cola del procesador es el conjunto de hilos que están listos, pero no podrá ser ejecutado por el procesador porque otro subproceso activo se está ejecutando actualmente. Una queue sostenida o recurrente de más de dos hilos es una clara indicación de un cuello de botella en el procesador. Se puede obtener más rendimiento al reducir el paralelismo en esos casos. Puede usar este contador junto con el contador Procesador \% de tiempo de procesador para determinar si su aplicación puede beneficiarse de más CPU.
Si cada procesador tiene 10 o más threads esperando, podría indicar que el procesador está a su capacidad límite
Si cada procesador tiene 10 o más threads esperando, podría indicar que el procesador está trabajando arriba de su capacidad
· \Network Interface(*)\Output Queue Length:
High Network I/O : más de 1 thread en espera de network I/O
Very High Network I/O: más de 2 threads en espera de I/O (si output queue length
es mayor que 2)
· \Network Interface(*)\Current Bandwidth (Este contador indica si el tráfico del adaptador de red está saturado):
High average network utilization: > 50%
Very high average network utilization: >80%
· Server\Bytes Total/sec (Este contador indica el número de bytes enviados y recibidos por la red. Los valores altos indican el ancho de banda de red como cuello de botella. Si la suma de Bytes Total / sec para todos los servidores es aproximadamente igual a las velocidades máximas de transferencia de la red, es posible que tenga que segmentar la red)
· \Process(*)\Private Bytes (Private es el tamaño actual, en bytes, de la memoria que este proceso ha asignado y no puede compartir con otros procesos)
Delta entre minimum size y maximun size no debe ser > 500MB
· \Process(*)\Working Set (Working Set es el tamaño actual, en bytes, del Working Set del proceso. Working Set es el conjunto de páginas de memoria que han sido accedidas por los threads del proceso. Si la memoria libre es mayor que un umbral las páginas se dejan en el Working Set incluso si no la están usando. Cuando hay poca memoria, se sacan del working set:
Delta entre minimum size y maximun size no debe ser > 500MB
· \Process(*)Thread Count (el número de threads activos en el proceso):
Para 2GB de memoria máxima, se recomienda un umbral de 6600 threads.
· \Process(*)\Handle Count (Determina cuantos handles ha abierto un proceso, un número grande indica leaks de handles o un procesamiento agresivo)
>3000 handles indica un comportamiento sospechoso. Algunas excepciones son System (20.000 handles), lsass.exe (30000), store.exe (50000), sqlsrvr.exe (50000)
- Utilizar siempre A records para los DNS de los servidores de SQL, ya que es necesario para configurar kerberos.
- Siempre mantener el servidor con los últimos patchs disponibles. En cada patch no sólo se solucionan bugs, sino se agregan mejoras de performance.
- Reinicios sanitarios: es recomendado reiniciar una vez por mes.
No hay comentarios:
Publicar un comentario