Probar la performance de nuestro storage mediante SQLIO y powershell

La idea ejecutar un par de pruebas de stress sobre nuestro storage para evaluar la performance del mismo. En Sharepoint el cuello de botella suele ser nuestro SQL Server, mediante este script podremos probar si nuestro storage soporta la carga de IOPS requerida para que Sharepoint funcione correctamente.

Current enviroment:

• Azure IaaS A6, Datacenter Sur de Brasil
• Disco C (perpetuo, no se ve afectado por reinicios de la VM)
• Disco D (temporario, Azure mantiene una partición D para workload temporario, ej: logs de Base de datos)

Primero descargamos el siguiente script y sqlio

http://gallery.technet.microsoft.com/scriptcenter/Storage-IO-Performance-d628bad9

http://www.microsoft.com/en-us/download/details.aspx?id=20163

Lo dejamos en una carpeta temporal del C, ej. C:\Temp

Editamos el archivo de powershel

Y cambiamos los parámetros.

Algunas cosas a tener en cuenta:

• Trata de tener la cantidad de threads menor o igual a la cantidad de vCPU (threads <= vCPU). Yo por ejemplo tenía 8 cores, y le setee 1 a 4 threads.
• SQL Server en general escribe sequencial, pero la idea es hacer un stress de nuestro storage, así que deja los dos.
• El tamaño de los bloques de I/O dependerá de si se usa Eager Writes o Lazy Writer, pero has una prueba con los tres valores (8,64 y 256 KB).

Una vez que se ejecuta nos mostrará un archivo html con toda la información (IOPS, latencia, etc)

Estos datos podemos pasarlo a un excel y ver una comparativa de performance de nuestro storage.

Ej: promedio de IOPS y latencia de todas las combinaciones

En general Sharepoint requiere que tengamos tiempos de latencia promedio de :

Datafiles: <= 15ms

Logs: <= 5 ms

Obviamente depende del tipo de base que manejemos y del tamaño. Ej: las bases de search son las bases que más IOPS requieren, o bases de datos relacionadas a record center podriamos tener una latencia entre 20ms a 10 ms.

Les dejo un link a post que realicé hace un tiempo sobre las mejores prácticas de SQL Server para Sharepoint.

http://todosharepoint.blogspot.com.ar/2014/03/mejores-practicas-sql-server-para.html

Les dejo el link para descargar todos los archivos:

http://1drv.ms/1qMe0fa

 

Algunos links interesantes para entender estos resultados:

http://www.brentozar.com/archive/2008/09/finding-your-san-bottlenecks-with-sqlio/

http://blogs.technet.com/b/josebda/archive/2013/03/28/sqlio-powershell-and-storage-performance-measuring-iops-throughput-and-latency-for-both-local-disks-and-smb-file-shares.aspx

http://blogs.msdn.com/b/sqlmeditation/archive/2013/04/04/choosing-what-sqlio-tests-to-run-and-automating-sqlio-testing-somewhat.aspx

http://blogs.technet.com/b/sqlpfeil/archive/2012/12/04/working-with-sqlio-and-analyzing-it-s-output.aspx

http://technet.microsoft.com/en-us/library/cc966412.aspx

http://technet.microsoft.com/en-us/library/ff758657%28v=office.15%29.aspx

Mejores Prácticas SQL Server para Sharepoint 2010/2013 (Best Practices SQL Server for Sharepoint 2010/2013)–Parte 3

Parte 1: Optimización de los servidores de SQL Server

Parte 2: Optimización de la instancia de SQL Server

Parte 3: Mantenimiento de SQL Server (acá estamos)

MANTENIMIENTO DE SQL SERVER

• Verificar que no haya bases de contenido con tamaño >=200 GB. Se recomienda crear una nueva base de contenido y mover sites collection a esa base (Move-SPSite).
• Verificar latencia de disco para las bases de datos: utilizar el siguiente ReadAndWriteLatency.

El script nos retornará la latencia de disco (Avg Read Transfer/ms, Avg Write Transfer/ms). Microsoft sugiere los siguientes thresholds:

Database data files:

· Target: <10ms

· Acceptable: 10-20ms

· Unacceptable: >20ms

Database log files:

· Target: <5ms

· Acceptable: 5-15ms

· Unacceptable: >15ms

• Ejecutar semanalmente DBCC CHECKDB. Puedes utilizar el script de Hallengren: http://ola.hallengren.com/sql-server-integrity-check.html  (recuerda NO utilizar checkdb con la opción de rebuild, en cualquiera de sus formatos)

EXECUTE dbo.DatabaseIntegrityCheck
@Databases = 'USER_DATABASES',
@CheckCommands = 'CHECKDB',
@PhysicalOnly = 'Y'

• Monitorear semanalmente por Wait Events. Puedes utilizar el siguiente script: WaitStats. Dependiendo de los eventos externos por los cuales SQL espera, se realizará una acción. Ej: agregar más CPU, distribuir los I/O, etc.  Más información

• Monitorear los growth de la tempDB. Deberían minimizarse al mínimo los growth de la tempDB. El siguiente script nos permite monitorear esos growth, y en el caso que haya muchos, deberíamos iniciar la tempDB con un tamaño mayor y tener tamaños más grande autogrowth: InitialSizeAndGrowth

• El siguiente script es similar al anterior, pero monitorea las bases de usuario. AutogrowthRecent

Si el script nos retorna que hubo >=7 growth para una base de usuario, significa que no está seteado correctamente el tamaño del autogrow.

Recuerda habilitar el trace en el caso que se haya deshabilitado.

select name, value_in_use

from sys.configurations

where name='default trace enabled'

Si value_in_use no es 1, se deberá habilitar.

sp_configure 'default trace enabled', 1

go

reconfigure with override

go

• Realizar desfragmentación de indices semalmente. Sharepoint tiene el store proc_UpdateStatistics, que realiza tareas de mantenimiento de indices. El problema de este store es que no se ejecuta para todas las bases de Sharepoint, sólo las de contendio. Se deberá ejecutar el siguiente script para evaluar la fragmentación de los índices:

Fragmentation Index.sql

Columna	Descripcion
avg_fragmentation_in_percent	El porcentaje de fragmentación lógica (páginas fuera de orden en el índice)
fragment_count	El número de fragmentos (páginas de hojas físicamente consecutivas)
avg_fragment_size_in_pages	Número promedio de páginas de un fragmento en un índice

Una vez verificado el estado de los índices, evaluar la siguiente tabla

avg_fragmentation_in_percent value	Sentencia correctiva
> 5% and < = 30%	ALTER INDEX REORGANIZE
> 30 %	ALTER INDEX REBUILD WITH (ONLINE= ON)

Para hacer un rebuild de los índices fragmentados, se deberá ejecutar el siguiente script (se utilizará el script de ola.hallengren.com):

1. Crear el procedimiento de desfragmentación de índices con el siguiente script

MaintenanceSolution.sql

2. Ejecutar el siguiente script

RebuildIndices.sql

El script anterior se puede crear un job para que se ejecute semanalmente (Sunday).

Ejecutar de nuevo el script FragmentationIndex.sql y ejecutar el siguiente script para verificar el estado de las estadísticas:

ReviewStatistics.sql

Si quieres utilizar el store de Sharepoint para desfragmentar los indices, puedes usar el siguiente script:

EXECUTE sp_msforeachdb
'USE [?];
IF DB_NAME() NOT IN(''master'',''msdb'',''tempdb'',''model'')
     begin
          print ''updating statistics in database  ==> '' + db_name()
          if exists (select 1 from sys.objects where name = ''proc_updatestatistics'')
             begin
                  print ''updating statistics via proc_updatestatistics''
                  exec proc_updatestatistics
             end
         else
             begin
                  print ''updating statistics via sp_updatestats''
                  exec sp_updatestats
             end
    end'

Más información en el siguiente link, link2.

• NUNCA hacer shrinks de datafiles (hay casos especiales, tales como borrado de mucha información, o tamaño excesivo de la base de crawl: link). Se puede hacer shrink de los logs, pero es preferible setear a modo simple las bases y evitar tamaños grandes de logs. En vez de Shrink de logs, se podría crear una buena política de backups y evitar el shrink, ya que al hacer el backup de las bases automaticamente realiza un shrink de los logs.
• En el caso excesivo de consumo de CPU y RAM en el crawl del Search, se puede utilizar Resource Governor. Link
• Verifica semanalmente las best practices definidas en el punto 2 de esta serie de post (Ej: auto update statistics=false, autoshrink=false, fill factor=80, etc)
• Instalar SQL Best Practices Analyser, y verificar mensualmente las mejores práctices (se actualiza de forma continua): http://www.microsoft.com/en-us/download/details.aspx?id=29302 (recuerda, no siempre las mejores prácticas de SQL Server aplican para Sharepoint)
• Semanalmente desfragmentar los volumenes donde se encuentran los datafiles de SQL Server. Una excelente herramienta para evaluar la fragmentación de los datafiles es contig de SysInternals.contig -a "E:\Data\nombreBaseDatos.mdf". Recuerda de poner la base de datos a offline y ejecutar el proceso de desfragmentación, al finalizar ponla de nuevo en online a la base de datos.
• Evaluar la base de datos que más memoria consume

MostMemoryXDatabase.sql

• Monitorear los archivos lógicos (VLF).Lo indicado en tener ente 20 a 100 vlf`s.  Más información en el siguiente link

ListVLFCounts.sql

En el caso que quiera evaluar específicamente la tempdb, puede ejecutar el siguiente comando:

DBCC LOGINFO

Para reducir la cantidad de vlfs, puede consultar los siguientes links:

http://blogs.msdn.com/b/saponsqlserver/archive/2012/02/22/too-many-virtual-log-files-vlfs-can-cause-slow-database-recovery.aspx

• Monitores útiles:

A continuación una lista de contadores a evaluar:

· Memory – Available MBytes

· Paging File – % Usage

· Physical Disk – Avg. Disk sec/Read

· Physical Disk – Avg. Disk sec/Write

· Physical Disk – Disk Reads/sec

· Physical Disk – Disk Writes/sec

· Processor – % Processor Time

· Processor – % Privileged Time

· Process: IO Read Bytes/sec

· Process: IO Read Bytes/sec

· Process (sqlservr.exe)

· SQLServer: Buffer Manager – Page life expectancy

· SQLServer: Buffer Manager – Lazy writes/sec

· SQLServer: General Statistics – User Connections

· SQLServer: Memory Manager – Memory Grants Pending

· SQLServer: SQL Statistics – Batch Requests/sec

· SQLServer: SQL Statistics – Compilations/sec

· SQLServer: SQL Statistics – Recompilations/sec

· System – Processor Queue Length

• Instalar SQL Server 2012 Performance Dashboard Reports

Se deberá instalar SQL Server 2012 Performance Dashboard Reports, el cual permite generar reportes de problemas de performance de forma rápida. Algunos reportes incluyen lo siguiente:

· CPU bottlenecks (and what queries are consuming the most CPU)

· IO bottlenecks (and what queries are performing the most IO)

· Index recommendations generated by the query optimizer (missing indexes)

· Blocking

· Latch contention

http://www.microsoft.com/en-us/download/details.aspx?id=29063

Mejores Prácticas SQL Server para Sharepoint 2010/2013 (Best Practices SQL Server for Sharepoint 2010/2013)–Parte 2

Parte 1: Optimización de los servidores de SQL Server

Parte 2: Optimización de la instancia de SQL Server (acá estamos)

Parte 3: Mantenimiento de SQL Server

OPTIMIZACION DE LA INSTANCIA DE SQL SERVER

• Setear Max Memory y Min Memory de la instancia.

Puede utilizar el siguiente script: Max Server Memory

Tendrás que setear dos variables dentro del script, y el mismo te generará un tamaño adecuado para el MaxMemory.

· MemToApps: default 512 MB

· RoomForOS: default 1 GB

Hay una fórmula que todos los consultores Sharepoint la utilizan:

SQL Max Memory = TotalPhyMem - (NumOfSQLThreads * ThreadStackSize) - (1GB * CEILING(NumOfCores/4))
NumOfSQLThreads = 256 + (NumOfProcessors*- 4) * 8    
ThreadStackSize = 2MB on x64 or 4 MB on 64-bit (IA64)  (*  If NumOfProcessors > 4, else 0)

Tanto el script como la fórmula, obtenes valores similares.

• Max Worker Threads:

Total available logical CPU’s <= 4: max worker threads = 512
Total available logical CPU’s > 4: max worker threads = 512 + ((logical CPUS’s - 4) * 16)

• Maxdop (Maximum Degree of Parallelization) = 1
• Collation para la instancia=Latin1_General_CI_AS_KS_WS
• Contained Database = 1 (sólo SQL Server 2012)
• Auto shrink = false
• Auto close = false
• Page verify = checksum
• Index Fill Factor = 80% (a nivel de instancia)
• Autogrowth = false

Deberá crecer en tamaños fijos, no mediante porcentaje:

1 GB para los datafiles (dependen del tamaño de la base, se recomienda 25% del tamaño de la base). Mi experiencia que 1GB es un buen tamaño para evitar la fragmentación (puede haber un pequeño tiempo de espera hasta que se aloca 1 GB, prefiero pagar ese tiempo y tener menor fragmentación).

256MB para los logs (25% del tamaño del datafile de la base.)

SIEMPRE es recomendable hacer un pre-growth (pre-allocate) de storage por 4 meses, pero esto genera mucho soporte del equipo de BD.

Para la tempDB utilice la siguiente formula:

[MAX DB SIZE (KB)] X [.25] / [# CORES] = DATA FILE SIZE (KB)

El “starting size” de la tempDB debe ser el 25% de la base de contenido más grande. En el post 3, les dejaré un script para obtener un valor inicial de tempdb más certero.

• Recovery model para base de datos de usuarios= full mode (depende de tu política de backups)
• Recovery model para la tempdb= simple mode
• Auto create statistics: false (en general es buena práctica habilitar esta feature, pero para el caso de Sharepoint se recomienda deshabilitar)
• Auto update statistics= false (misma consideración que el punto anterior.)
• Auto update statistics asynchronously= false (misma consideración que el punto anterior.)
• Se debe 1 datafile por virtual core para la tempdb: ej: si yo tengo una VM con 8 cores, debo tener 8 datafiles. Max Files=8 (no hay mejora después de los 8 datafiles) y todos los datafiles de la tempdb deben ser del mismo tamaño (proportional fill algoritm). Algunos recomiendan tener 1/4 o 1/2 datafile por core (link, link2, link3), yo siempre use 1 datafile por core y nunca tuve problemas, así que sigo recomendando esa configuración. Si distribuyes esos datafiles en distintas LUNs tendrás una mejoría importante.

Otra recomendación es tener 1 sólo transaction log para la tempdb (link). El tamaño de este transaction log debe ser el 25% de la base más grande.

Los nombres de los datafiles deben ser: tempdb1, tempdb2, tempdb3, etc

Ej: 4 cores

• Siempre hacer un pre-size de storage de la tempdb
• Habilitar el trace flag 1117 (permite mantener los datafiles siempre con el mismo tamaño al hacer growth), se utiliza mucho para la tempdb.
• Habilitar Instant File Initialization: especialmente para la cuenta que ejecuta el servicio de SQL Server. Se deberá setear la policy “Perform volume mintenance task”. Los logs NO son afectados por este feature.
• IOPS recomendados: 2 por GB de dato para una performance optima. Sharepoint soporta hasta .25 por GB de dato.
• Utilizar alias para la configuración de Sharepoint (link)
• Raid 10 para tempDB
• Cada 4 web servers (WFE) es recomendable tener otra instancia de SQL Server (otro servidor)
• IOPS necesarios

Las bases que más consumen IOPS son las bases de Search (links)

Les recomiendo leer la siguiente pptx para tener un mejor capacity planning del Search:

http://video.ch9.ms/sessions/teched/na/2013/SES-B310.pptx

Las bases de contenido pueden variar entre 200 IOPS a 4000 IOPS, dependiendo del uso del contenido (Documentos, Videos, etc).

Las demás bases pueden variar entre 100 IOPS a 200 IOPS.

Les dejo un resumen para que lo tengan como referencia:

• Calcula prematuramente el tamaño estimado que vas a tener en la granja

Database size = ((D × V) × S) + (10 KB × (L + (V × D)))

10KB es el valor promedio de metadata que es requerido por SP2013.

D=Número de documentos

S=Tamaño promedio de los documentos

L=List Items

V=Número de versiones no actuales

• SP2013 utiliza Shredded Storage, se recomienda dejar las settings por default de esta feature. Video, Video2, Documento Técnico.
• Revisar el doc de límites relacionados a la base de datos: http://technet.microsoft.com/en-us/library/cc262787(v=office.15).aspx#ContentDB
• Latencia de disco :

Database data files:

     · Target: <10ms

     · Acceptable: 10-20ms

     · Unacceptable: >20ms

Database log files:

     · Target: <5ms

     · Acceptable: 5-15ms

     · Unacceptable: >15ms

Orden de prioridad:

     · tempDB data y logs files

     · Database transaction logs

     · Seach Data files

     · Content Database data files

• Read Committed Snapshot Isolation NO está soportado
• Configurar ModelDB: con parametros similares a los definidos para la content database.
• NO se debe realizar consultas sobre la base de datos (puede ocasionar locks y rebuilds del schema): En el siguiente Link podrás encontrar más información. La UNICA base en la que se puede realizar queries es WSS_Logging. Link, Link 2. En el caso que quieras hacer queries contra la bases de Sharepoint, has un backup y utiliza ese backup para realizar queries.
• Compress Backups = True
• NO se puede ejecutar DBCC CHECKDB WITH REPAIR o sus variantes (no soportado). Si se puede ejecutar los siguientes comandos:
  • DBCC CHECKDB
  • DBCC_CHECKDB WITH REPAIR_FAST
  • REPAIR_REBUILD
• Tener bases de contenido con tamaño máximo de 200GB (no es un límite de Sharepoint, es por cuestiones de administración principalmente)
• Configurar la instancia de SQL Server con Mixed Mode, ya que el servicio de Access Service lo requiere.
• Utiliza standarts para los nombres de las bases de datos.

Tipo	Nombre
Configuration	SP_<Farm ID>_Config
Content DB	SP_<Farm ID>_Content_<Nombre o Propósito> Ej: SP_FCentral_Content_Intranet , donde FCentral hace referencia a la granja central
Service Application	SP_<Farm ID>_Content_<Service Application>

• Instalar siempre el último CU disponible para SQL Server (a la escritura de este post era el CU 9)
• Latencia entre los servidores de SQL Server y los de Application Server/WFE < 1 ms
• Excluir del antivirus las siguientes extensiones: *.mdf, *.ndf, *.ldf, *.bak. En el caso que tengas un cluster, también <$windir>/cluster
• Utilizar la versión Enterprise de SQL Server

Mejores Prácticas SQL Server para Sharepoint 2010/2013 (Best Practices SQL Server for Sharepoint 2010/2013)–Parte 1

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.

Links útiles #29 Sharepoint 2013

1-Introducción a WOPI en Office Web Apps 2013

El siguiente articulo nos introduce en una nueva feature de Office Web Apps llamada WOPI (Web Application Open Platform Interface), el cual provee funcionalidades para ver y editar documentos desde apps externas

http://blogs.msdn.com/b/officedevdocs/archive/2013/03/20/introducing-wopi.aspx

2-Translations en Sharepoint 2013

Los siguientes artículos nos muestran como usar la feature Translations de Sharepoint 2013

http://blog.amtopm.be/2013/03/10/using-export-translations-and-import-translations/

http://www.mavention.com/blog/support-translation-sharepoint-2013

3-Remote Blob Staorage (RBS) para Sharepoint 2013

El siguiente artículo nos indica como activar implement Remote Blob Storage (RBS) usando FileStream Provider.

 

http://stevemannspath.blogspot.com.ar/2012/07/bang-two-pound-four-remote-blob-storage.html

4-Tuning SQL Server 2012 para Sharepoint 2013

Los siguientes videos nos guiarán para configurar SQL Server 2012 de forma correcta para soportar Sharepoint 2013 con las mejores prácticas.Super recomendado.

• Mod 01: Key SQL Server and SharePoint Server Integration Concepts
• Mod 02: Best Practices for SQL Server Database Settings
• Mod 03: Server Settings for SQL Server
• Mod 04: SQL Server and SharePoint Availability

5-Comparación de Office 365 (Sharepoint Online) con Sharepoint 2013 On-premise

En el siguiente se publica una matrix de comparación de Sharepoint Online y Sharepoint 2013 On Premise.

https://skydrive.live.com/?cid=bdded38f29ae68b5&id=BDDED38F29AE68B5%21475#!/view.aspx?cid=BDDED38F29AE68B5&resid=BDDED38F29AE68B5%216076&app=Excel

SharePoint Performance Troubleshooting

Para ver el post completo: http://www.sharepointpromag.com/article/sharepoint-server-2010/sharepoint-performance-troubleshooting-141506

 

Windows Server Hardware Sizing

You need to correctly size your hardware to support the SharePoint tier that is being hosted. You'll also need to ensure that Windows Server has been optimized.

For the optimal RAM profile, examine what your app pools will require, multiply that number by the number of app pools that you expect to have, and then add half again as much to ensure room for growth and the occasional application that doesn't dispose properly:

(Required RAM) ´ (# of App Pools) ´ 1.5 = Proposed RAM Profile

Hard disk space is a fairly straightforward decision: 80GB is never going to be enough. Each web and application server will have its own Microsoft User Location Server (ULS), IIS, and event logs; copy of the 14 hive; and WinSxS directory. Add the need for a pagefile that doubles your RAM count and a desire to make sure that your server doesn't crash because you didn't have enough disk space. I recommend a minimum of 200GB per server -- 400GB if you can afford it. Rather than splitting drives into multiple partitions, keep a single, larger C partition to manage growth.

Top 10 SharePoint 2010 Configuration Mistakes -- and How to Fix Them

Ver el post completo:http://www.sharepointpromag.com/content1/topic/sharepoint-2010-misconfigurations-141636/catpath/sharepoint

 

Mistake #1: Scrimping on SharePoint's RAM or Hard Disk Space

Virtualization itself isn't bad, but it must be done intelligently and without sacrificing SharePoint's ability to do its job.

If SharePoint finds itself starved for RAM, it starts shutting off functionality so that it can fit into the available space. It also caches less in the web application pools and recycles those pools more often. Less caching and more recycles result in a degraded end-user experience, as SharePoint must compile the same ASP.NET code over and over. And no one likes unhappy users, not even their mothers.

The solution to this particular issue is easy: Add RAM.

 

Mistake #2: Using Virtualized Microsoft SQL Server

Virtualization isn't bad. But virtualization allows administrators to make mistakes on a much grander scale. Take virtualizing SQL Server. Everything in SharePoint is stored in SQL Server, if SQL Server is slow, SharePoint is slow.

The obvious solution is to move SQL Server to a physical box.

 

 

Mejores Prácticas Sharepoint 2010 (Artículo 2)

Best Practices for SharePoint Server 2010

Este post es una continuación del siguiente: http://todosharepoint.blogspot.com/2012/01/mejores-practicas-sharepoint-2010.html

Team collaboration

1. Plan and allocate database servers to support collaboration
2. Monitor sites and content, and perform cleanups regularly
3. Enforce site and content size limits
4. Manage security and permissions
5. Read details and more best practices >

My Sites

1. Use My Sites to promote social networking and enterprise collaboration
2. Deploy My Site farms based on the geographical distribution of your workforce
3. Plan for improved performance
4. Isolate My Sites in a dedicated Web application
5. Read details and more best practices >

 

Mejores Prácticas Sharepoint 2010 (Artículo 1)

Best Practices for SharePoint Server 2010

Operational excellence

1. Use lots of memory and fast network adapters
2. Stay close: Do not put too much network distance between front-end Web servers, application servers, and database servers
3. Consider performance and availability when you configure Web servers and application servers
4. Consider performance and availability when you configure database servers
5. Read details and more best practices >

Virtualization

1. Use hardware-assisted virtualization
2. Enable hyper-threading on processors that support this technology
3. Configure Non-Uniform Memory Access correctly
4. Configure the Hyper-V host for optimal performance
5. Read details and more best practices >