Hyper-V Performance – Parte IV – Red.

Me quedé sin espacio en la base de datos de mi WordPress en Azure, así que continuamos en “MasRobeznoQueNunca” hasta que solucione este pequeño problema.

Hoy continuamos con la monitorización de la red.

Después de haber visto la monitorización mas complicada como es la de Almacenamiento o la de memoria, la monitorización de rede la vamos a basar en dos simples contadores, uno para la tarjeta del host y otro para la tarjeta de las Máquinas Virtuales (VM):

a) Tarjeta de red del Host.- El siguiente contador indica el total de Bytes por segundo tanto de tráfico de entrada como de salida en una tarjeta de red física (NIC).

Network InterfaceBytes Total/Sec

Con la siguiente horquilla de valores recomendados:

0001

No tenemos que olvidar detalles tan importantes como la velocidad de nuestra tarjeta de red, como por ejemplo:

  • NIC de 10 GB puede enviar cerca de 1250 millones de bytes/sec
  • NIC de 1 GB puede enviar cerca de 125 millones de bytes/sec
  • NIC de 100 MB puede enviar cerca de 12,5 millones de bytes/sec

y la velocidad de los Switches o Routers a los que está conectado, ya que aunque tengamos la posibilidad de configurar las tarjetas de red a 10 GB si los Switches son de 1GB ……

.

b) Tarjeta de red de la VM.- En el caso de que queramos estudiar el tráfico de las tarjetas de red virtuales (vNIC), utilizaremos el siguiente contador que representa el número total de byts que atraviesan dicho adaptador virtual.

Hyper-V Virtual Network AdapterBytes Total/Sec

Utilizaremos la misma horquilla descrita en el punto anterior.

Buena semana a todos.

Hyper-V Performance – Parte III – Almacenamiento.

 

Continuamos con esta serie de Post sobre como medir el rendimiento de nuestros Hyper-V, despues de la CPU y la memoria RAM, hoy nos toca el almacenamiento.

 

El almacenamiento suele ser uno de los puntos donde se originan mas cuellos de botella en nuestra infraestructura. Detectar dichos problemas suele ser uno de los dolores de cabeza mas frecuentes del informático. En Hyper-v no va a dejar de ocurrir lo mismo. Lo vamos a dividir en tres partes:

 

a) Logical Disk.- Tenemos estos tres contadores de rendimiento recomendados de Disco lógico, como podreis intuir se trata de monitorizar si tenemos latencia en lectura, escritura y en transferencia por segundo, en valores medios:

\LogicalDisk\Avg Disk sec/Read0001

\LogicalDisk\Avg Disk sec/Write

\LogicalDisk(*)\Disk Transfers/sec (IOPS desde el punto de vista de Windows).

Utilizaremos el siguiente baremo recomendado por Microsoft para saber si nuestros discos están en estado saludable o tenemos latencia:

 

b) Physical Disk.- Tenemos los mismos contadores de rendimiento recomendados que en punto de Disco lógico, lectura, escritura y transferencia por segundo en valores medios. Además utilizaremos la misma horquilla para saber si tenemos latencia o no.

 

\Physical Disk\Avg Disk sec/Read

\Physical Disk\Avg Disk sec/Write

 \LogicalDisk(*)\Disk Transfers/sec

 

En el caso que estemos utilizando Cluster Shared Volumes (CSV) conectados como discos Passthrough, tendremos que monitorizarlos no solo para saber si tenemos latencia, también para ver el grado de fragmentación de dicho disco.

 

\Physical Disk(*)\Disk Transfers/sec (* CSV monitoring)

 

También tendremos que tener especial cuidado si hemos montado nuestra infraestructura de virtualización aprovechando las bondades de Server Message Block (SMB), ya en versión 3, con los siguientes contadores:

 

\SMB Clients Share\Avg Disk sec/Read

\SMB Clients Share\Avg Disk sec/Write

 

Es dificil poner un baremo en estos contadores ya que siempre dependerá de la infraestructura de red que tengamos.

 

c) Hyper-V Storage.- Estos contadores representan el número total de bytes que han sido leidos o escritos por segundo en el dispositivo virtual. Es complicado poner un baremo ya que en todo momento depende del tipo de almacenamiento físico que estemos utilizando:

 

\Hyper-V Virtual Storage Device\Read bytes/Sec

\Hyper-V Virtual Storage Device\Write bytes/Sec

 

Cada fichero VHD o VHDX tendrá su propia instancia de contador de rendimiento y lo utilizaremos para determinar qué disco tiene mas o menos utilización (IOPS).

Como podreis comprobar hay innumerables post en blogs sobre el rendimiento y el almacenamiento, hay mucha información, en general, sobre el rendimiento. Os enumero unos poquitos:

Hyper-V Performance – Parte II – Consumo de Memoria.

Continuo con esta serie de Post sobre como medir el rendimiento de nuestros Hyper-V, despues de la CPU hoy llega la memoria RAM.

 

Obviamente lo dividimos en la parte del Host de virtualización, ya sea Windows Server 2012 con el rol de Hyper-V o sea Hyper-V server 2012, y la parte de las máquinas virtuales (VMs).

 

Host.- Los principales contadores para monizar la memoria del Host son los siguientes:

 

  • \Memory\Available MBytes.- Microsoft nos recomienda monitorizar la memoria disponible de cada Host de virtualización a través de esta orquilla de valores:

0001

  • \Memory\Pages /Sec.- Con este contador monitorizaremos las páginas que se están leyendo o escribiendo en disco por segundo, para tratar de detectar errores de paginación, o sea, que tengamos un caso que el sistema operativo no dispone de mas memoria disponible y está utilizando el disco duro para volcar el resto de  memoria que necesita, con su correspondiente impacto negativo en el rendimiento.   Microsoft nos recomienda esta orquilla de valores a la hora de medir este contador:

0002

Como ejemplo, un alto número de paginas por segundo unido a una baja memoria disponible nos está indicando una falta de memoria en el servidor, obviamente.

 

Recordamos los principios básicos de la relación existente entre la memoria y la paginación a disco “a mas memoria RAM asignada a un equipo menos paginará en disco“, sin olvidarnos de que “no siempre disponemos de toda la memoria RAM que queremos y/o necesitamos”.

 

Virtual Machines.- En este caso se nos presentan dos opciones de configuración en la gestión de la memoria:

 

  • Sin memoria Dinámica configurada.- Al no tener configurada esta característica, utilizaríamos los mismos contadores que para un Host de virtualización. Volvemos al punto anterior.

 

 

  • Con memoria Dinámica configurada.- Tenemos los siguientes contadores de rendmiento:
  • \Hyper-V Dinamic Memory Balancer\Available Memory.- Este contador representa la cantidad de memoria que queda disponible en el “nodo balancer” (gestor del balanceo de memoria entre las VM cuando están configuradas con memoria dinámica), y que puede ser asignada a las VMs.

Aqui prestaremos atención a que el valor de dicho contador no esté próximo a 0, que nos indicará que el sistema está cerca del consumo del 100% de la memoria, con los consiguientes problemas de rendimiento en las mismas.

  • \Hyper-V Dinamic Memory Balancer\Physical Memory.- Este contador representa la cantidad de memoria en la VM. Es muy util para entender el consumo histórico de una VM.

Tendremos que tener cuidado de que el valor que nos da este contador no esté cerca de la memoria máxima asignada, ya que nos indicaría que este servidor está consumiendo toda su memoria RAM y, probablemente, esté paginando a disco y necesite mas.

  • \Hyper-V Dinamic Memory Balancer\Average.- Este último contador representa la presión media sobre el “nodo balancer”. Esta es la orquilla de valores recomendados:

0003

 

Por defecto en Windows Server 2012 con el rol de Hyper-V, automáticamente se fija una memoria para el Host. Para sistemas operativos anteriores, como Windows Server 2008 R2, necesitamos habilitar y configurar una entrada en el registro:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization

  • Nombre:MemoryReserve
  • Tipo: DWORD
  • Valor: Memoria a reservar en MB.

 

Dos cosas para terminar. Recordar que estos datos no son extrapolables al 100% a todos y cada uno de nuestros entornos, como ya dije en el Post anterior, son recomendaciones. Y, segundo, recordar, también, en el caso de configurar memoria dinámica a las VMs, qué parámetros tenemos que tener en cuenta:

 

Buena semana a todos,

Hyper-V Performance – Parte I – Consumo de CPU.

Aprovechando que hace poco estube en un Workshop en Microsoft sobre el rendimiento de nuestros servidores con el rol de Hyper-V, adelanto esta serie de Posts sobre “cómo medir dicho rendimiento así cómo detectar posibles cuellos de botella en nuestro entorno de virtualización”.

Para empezar, me gustaría recordar este Post sobre “10 errores típicos en una revisión de salud de un entorno de Virtualización“, que considero indispensable releer cada vez que me meto en un proyecto de virtualización, independientemente del tipo de Hypervisor que se vaya a utilizar.

 

0001

i) Host Processor.- Normalmente en cualquier servidor, si queremos verificar el consumo de nuestro procesador lo que haremos será cargar los siguientes contadores de rendimiento:

 

  • \Processor(*)\% Processor Time
  • Task Manager (ver imagen =>)
  • \System\Processor Queue Lenght

 

Pues en nuestro caso, para saber qué consumo tiene la partición padre, que no hay que olvidar que es una máquina virtual (VM) en si misma, ya sea Hyper-V Server 2012 o Windows Server 2012 con el rol de Hyper-V, serán los mismos.

 

Veamos en que rangos de consumo de tiempo de procesador nos movemos:

0003

En el caso de que hayamos visto o intuyamos que pueda haber un problema de rendimiento en la CPU, o sea, nos hayemos en la zona de Caution o Critical, utilizaremos el contador de la Longitud de la cola del procesador, como referente inicial disponemos de la siguiente horquilla de valores que nos puede ayudar:

0002

Siempre hay que tener en cuenta que si ocurre en un momento puntual, no pasa nada. Otra cosa es que estos valores se alcancen durante un tiempo continuado. En cuanto a la horquilla de valores, éstos son orientativos, hay que saber extrapolarlos a las situaciones reales, a la carga del servidor, a los roles que tengamos instalados en el mismo, etc., no cogerlos como una regla de tres o lo que dice el KB de Microsoft va a Misa.

 

ii) Logical processor.- Para medir el total del consumo de procesador por parte del Host y todas las VM, utilizaremos los siguientes contadores de rendimiento:

  • \Hyper-v Hypervisor Logical Processor(*)\% Total Runtime
  • \Hyper-v Hypervisor Logical Processor(*)\Context Switches /Sec

% Total Runtime, con su consiguiente horquilla de valores indicativos (si os fijais son los mismos que en el punto anterior):

0003

Para el caso de los Content Switches, ocurren cuando el kernel cambia el procesador asignado de un subproceso a otro, verificaremos cuántos se producen por procesador y por segundo, con la consiguiente horquilla de valores indicativos:

0004

Cuando detectamos que estamos en zona Critical, suele venir motivado por:

  • Adaptadores del tipo Legacy Network.
  • Mal diseño de aplicaciones.
  • Drivers mal instalados.

 

ii)  Virtual processor.- Determinar el consumo de procesador de cada VM:

  • \Hyper-v Hypervisor Virtual Processor(*)\% Guest Runtime

Con la misma o muy parecida horquilla de valores indicativos que en el punto anterior:

0005

Como consejo final, si detectamos que \Hyper-V Hypervisor Virtual Processor (_Total)\% Total Run Time (Virtual Procesor Total Run Time – VPTR) está muy alto y \Hyper-V Hypervisor Logical Processor (_Total)\% Total Run Time (Logical Procesor Total Run Time – LPTR) es bajo, consideremos en asignar procesadores adicionales a esa VM.

El próximo día la memoria RAM.

Exchange 2010 Architecture Report

Hola. Hoy os traigo este script que nos proporciona información arcerca de nuestra Organización de Exchange 2010. Lo podeis descargar desde Aqui.

Esta herramienta nos genera un reporte en formato HTML para presentar todos los datos recolectados donde podemos ver qué es lo que funciona y lo que no de un simple vistazo.

Tiene tanto un acceso por Interfaz gráfica (GUI) como por comando. Esta última la podemos utilizar para generar tareas programadas y generar informes de chequeo.

Espero que os guste y os sirva.

Servicio Back Pressure en Exchange 2010.

Recordamos que este servicio monitoriza y supervisa los parámetros principales en los servidores con el rol Hub Transport Server, aquellos que se encargan de mover todos los correos en la Organización. 
Back Pressure tiene los siguientes estados:
  • Normal.- Los recursos son correctos. El servidor acepta nuevas conexiones y mensajes. Todo correcto.
  • Medium.- Los recursos se están acabando. Los correos desde dominios autoritativos pueden ser enviados. Dependiendo de los recursos de que se disponga, el servidor empezará a retrasar respuestas o a rechazar comandos “MAIL FROM” de otras fuentes.
  • High.- Cuando se entra en este estado es que no hay recursos. Todos los flujos de mensajes se paran y se rechanzan todas las conexiones entrantes.
Nos centraremos en el Espacio libre en disco y la Memoria utilizada:
·         Espacio libre en disco.- Verificará el espacio libre en disco de las siguientes colas:
o   Queue database, normalmente lo tendremos en un disco a parte del de Sitema Operativo.
o   Queue database transaction logs. Igual que el anterior.

Para la base de datos Queue:

·         Alto.-  La fórmula que utiliza es la siguiente: Free space percentage= (disk size -512 MB)/disk size y se trabajará sobre porcentajes. Por ejemplo, si tenemos ubicadas dichas bases de datos en dos discos, disco X de 72 GB y disco Y de 100 GB:
Disco X: (71.577,6 – 512)/71.577,6 = 0,99 ==> 99%.
Disco Y: (102297,6 – 512)/102297,6 = 0,99 ==> 99%.
·         Medio.-  Será un 2% menor del nivel alto, o sea, un 97%.
·         Normal.- Será un 4% menor que el nivel alto, o sea, un 95%.
Para la base de datos del Log de transacciones se multiplica por tres el valor de 512MB:
·         Alto.-  La fórmula que utiliza es la siguiente: Free space percentage= (disk size –(512*3) MB)/disk size y se trabajará sobre porcentajes. En nuestro caso es el siguiente:
Disco X: (71.577,6 – 512)/71.577,6 = 0,978 ==> 97%.
Disco Y: (102297,6 – 512)/102297,6 = 0,984 ==> 98%.
·         Medio.-  Será un 2% menor del nivel alto, o sea, un 95% en disco D y un 96% en disco L.
·         Normal.- Será un 4% menor que el nivel alto, o sea, un 93% en disco D y un 94% en disco L.
El parámetro fijo (en este caso 512MB) vendrá dado en el fichero EdgeTransport.exe.config en la llave DatabaseCheckPointDepthMax. Por defecto son 512MB:
·         Memoria.-Se monitorizan dos parámetros:
o   Memoria usada por el proceso EdgeTransport.exe, que es el servicio Microsoft Exchange Transport service. Cálculo de los niveles, si, por ejemplo, tenemos asignado 8 GB de memoria RAM:
·         Alto.-  75% sobre toda la memoria física del servidor. ==> 8 GB * 75% = 6 GB.
·         Medio.-  Será un 2% menor del nivel alto, o sea, un 73%. ==> 8 GB * 73% = 5,84 GB
·         Normal.- Será un 4% menor que el nivel alto, o sea, un 71%. ==> 8 GB * 71% = 5,68 GB.
o   Memoria usada por el resto de procesos del servidor. Cálculo de los niveles:
·         Alto.-  94% sobre toda la memoria física del servidor. ==> 8 GB * 94% = 6 GB.
·         Medio.-  Será un 2% menor del nivel alto, o sea, un 73%. ==> 8 GB * 73% = 5,84 GB
·         Normal.- Será un 4% menor que el nivel alto, o sea, un 71%. ==> 8 GB * 71% = 5,68 GB.
Backup Pressure también monitoriza  el número de mensajes no confirmados de la base de datos de transacciones en memoria, pero de esto tengo que buscar mas información que he encontrado muy poca.

¿Cómo se refleja esta situación en nuestro servidores? Normalmente lo detectaremos en el visor de eventos:

O si tenemos alguna herramienta de monitorización, como SCOM, nos lo irá reportando. De todas maneras, espero que no os aparezca jamas.

Bibliografía:
Technet

Medición del rendimiento – ¿Cómo detectar problemas de latencia en disco en VMware vSphere ESXi?

Continuando con las mediciones del rendimiento de nuestros servidores, llevaba tiempo para sacar un Post sobre cómo detectar problemas de latencia en discos, tanto FC, iSCSI como NFS, al menos desde que hice el curso para la obtención de la certificación VCP-410 y, hoy, al hilo de un artículo aparecido en el Blog de la Virtualización en Español, de nuestro gran maestro Jose María Gonzalez, retomo una de sus enseñanzas.

¿Cómo detectar problemas de latencia en disco de un ESXi? Dentro de nuestra herramienta de rendimiento, nos fijaremos en los siguientes contadores:

  • Kernel command latency.- tiempo medio empleado por el VMkernel para procesar un comando SCSI. Un número alto en este contador, (entre 2 a 3 milisegundos, puede significar:
    • Que la cabina tenga un exceso de trabajo
    • O que el servidor ESX/ESXi tenga un exceso de trabajo.
  • Physical device command latency.- Mide el tiempo medio que el dispositivo físico (disco) necesita para completar un comando SCSI. Un número alto en este contador (depende d la cabina, pero, en general, este valor está entre 15 y 20 milisegundos), puede significar dos cosas:
    • O la cabina va muy lenta.
    • O la cabina tiene un exceso de trabajo.

Vayamos a un ejemplo real. Configuro el primer contador (Kernel command latency) para mi cabina de discos y este es el resultado:

En este caso nos fijamos en el último dispositivo, que es el que no está dando unos valores anómalos. Como se puede apreciar, la SAN es una HITACHI.

Por otro lado, ahora nos fijamos en el segundo contador, (Physical device command latency). Este valor, en principio, nos tiene que venir dado por el fabricante de la cabina, en mi caso HITACHI, pero yo no lo he conseguido. Me voy a basar en los estándares.

En este caso tenemos que los siguientes discos:

  • t10.HITACHI_770501211902.- Este disco está por encima de los 20 milisegundos.

  • t10.HITACHI_770501211901.- Este disco ronda los 11 milisegundos en media con ligeros picos por encima de los 20 milisegundos.

¿Cómo seguir desde aquí? Bien, sabemos qué maquinas componen la citada LUN, en mi caso contiene las siguientes Máquinas Virtuales (VM):

Habría que ir moviendo una a una cada VM a otra LUN y verificar cuál es la que está provocando este fallo.

El próximo día Iperf en modo gráfico.

Un saludo,

Medición del rendimiento – Networking con Iperf.

Uno de los problemas más difíciles de detectar hoy en día en las “grandes empresas” es ver que el rendimiento de la red es el correcto. Digo grandes empresas ya que o tienen subcontratados los departamentos de comunicaciones, o siendo de la misma empresa, se llevan a matar. Este es mi caso pero con una salvedad, aquí se inventó la técnica de “balones fuera”.

Al grano. Utilizaremos la herramienta Iperf, válida para sistemas operativos tales como Sun Solaris, Linux, Windows, etc. Estos son todos los parámetros:

Destacamos los siguientes parámetros:

  • -D    instalación como servicio.
  • -R    Desinstalación (remove) como servicio.
  • -i    intervalo de tiempo en segundos entre reportes.
  • -l    longitud del buffer a leer o escribir (por defecto 8 KB)
  • -u    recepción de datagramas UDP en vez de tramas TCP que es la opción por defecto.
  • -P n    donde n es el nº de conexiones simultáneas.
  • -t    tiempo en segundos de transmisión (10 segundos por defecto)
  • -w    tamaño de ventana TCP.
  • -f[bkmBKM] formato del resultado: bits/s, kilobits/s, megabits/s, Bytes/s, KiloBytes/s, MegaBytes/s.

Pruebas realizadas:

i) Básica.- Definimos un equipo como servidor y otro como cliente y ejecutamos el aplicativo en ambos equipos.-

Ejecutamos en el equipo servidor Iperf -s

Ejecutamos en el equipo cliente Iperf –c <equipo servidor>

En este caso tenemos un ejemplo claro de una pobre comunicación en una red de 100MBits. 38,7 Mbits/sec.

En este otro caso tenemos una mejor comunicación en una red de 100MBits. 75,1 Mbits/sec.

ii) Parametrizada.- Como hemos visto en la definición del comando vamos a utilizar los siguientes parámetros:

Servidor: Iperf –s –f MB –i1 (tamaño en MegaBytes e intervalos de 1 segundo)

Cliente: Iperf –c 10.144.8.123 –f MB –t 30 (tamaño en MegaBytes y durante 30 segundos de duración)

Bibliografía.

El próximo Iperf gráfico, Iometer, etc.

Un saludo,

Eventtriggers – Desencadenador de eventos.

Ya estamos aquí de nuevo.

Existe una herramienta de línea de comandos llamada eventtrigers.exe la cual he descubierto hace relativamente poco y cuya función es hacer de desencadenador de eventos. Os pongo un ejemplo práctico.

Tengo un servidor con un problema (típico). Cada x tiempo, por ejemplo, los lunes y los jueves, el servicio RPC me bloquea toda conexión por parte de los usuarios al servidor, quedándome sin servicio, por lo que tengo que reiniciarlo. El único dato que tengo es un evento que se genera, por ejemplo este:

Tipo de suceso: Error

Origen del suceso: NETLOGON

Categoría del suceso: Ninguno

Id. suceso: 5719

Fecha: 28/06/2009

Hora: 14:05:11

Usuario: No disponible

Equipo: ROBEZNO_SER

Descripción:

Este equipo no pudo establecer una sesión segura con un controlador de dominio en el dominio SAURON debido a lo siguiente:

Espacio de almacenamiento insuficiente para procesar este comando.

Esto puede derivar en problemas de autenticación. Asegúrese de que el equipo esté conectado a la red. Si el problema persiste, póngase en contacto con el administrador del dominio. .

¿Qué hacer?

Vamos a crear un desencadenador de eventos, para que cada vez que ocurra este evento realice una acción, en concreto, ejecutará un archivo .cmd que a su vez reenvía un mail al administrador para que reinicie el servidor antes que los usuarios lo requieran:

Desde una consola ejecutamos: Eventtriggers /create /tr ErrorNetlogon /l System /eid 5719 /tk c:ErrorNetlogon.cmd

Exactamente estamos creando un desencadenador para que cada vez que aparezca el evento con ID 5719 realice la acción de ejecutar el fichero c:ErrorNetlogon.cmd, o sea:

bmail -s SRVMAIL -t sistemas@robezno.com -f ROBEZNO_SER@robezno.com -h a “Evento de error en servidor ROBEZNO_SER” -b “Ha aparecido el evento de error 5719 de NETLOGON. Habrá que reiniciar el Servicio RPC o el Servidor”

He utilizado la herramienta bmail en este ejecutable para el envío de un mail. Muy útil.

Por lo que he podido ver, tanto en la documentación como en otros blogs, esta herramienta se utiliza para ejecutar un fichero de acciones o para realizar una tarea, por ejemplo una limpieza de disco, reinicio de servicios, etc.

Hasta la próxima, Robeznos.

Rendimiento II – Interpretación de los contadores de rendimiento.

Hola,

Ya sabéis como es este mundillo de los contadores de rendimiento. Yo quiero romper una lanza en favor de una herramienta que me ha sorprendido mucho: Performance Analysis of logs (PAL).

Existe mucha literatura sobre qué tipo de contadores poner para detectar problemas, esto, sin olvidarnos de que cada maestrillo tiene su librillo, por no decir, yo soy el que sabe tu no, o haz lo que te digo, y, para terminar, mira chaval estás dando palos de ciego.

Como ya sabemos poner contadores, esta herramienta lo que hace es tratarlos y aportarnos información y análisis gráficos de dichos datos.

i) Configuración.- Ejecutamos el programa. Nos aparece la pantalla de bienvenida:

Ponemos la ruta donde están nuestros logs a analizar:

Seleccionamos el tipo de análisis que queremos realizar.

Tenemos estas opciones:

  • Microsoft Active Directory
  • Microsoft BizTalk Server 2004
  • Microsoft BizTalk Server 2006
  • Microsoft Exchange 2003
  • Microsoft Exchange 2007 – CAS
  • Microsoft Exchange 2007 – HUB
  • Microsoft Exchange 2007 – HUB/CAS
  • Microsoft Exchange 2007 – Mailbox
  • Microsoft Exchange 2007
  • Windows 2008 Hyper-V
  • Microsoft Internet Information Services 5.0/6.0
  • Microsoft MOSS 2007
  • Quick System Overview
  • Microsoft SQL Server 2000
  • Microsoft SQL Server 2005
  • System Overview.

Sin olvidarnos que podemos escoger parámetros adicionales como el /3GB, el número de procesadores, el total de memoria, etc.

Seleccionaremos el intervalo de análisis (en este ejemplo he puesto todo):

Directorio de salida y formato de la misma:

Script que se genera con toda la información aportada:

Ejecución:

Esto es lo que vemos mientras se ejecuta:

ii) Ejemplo.-

Este es el resultado que nos da la herramienta, en formato html:

Donde podemos ver información tal como % del tiempo de procesador, que en nuestro caso es correcto:

O nos puede dar información sobre posibles problemas (warnings). En concreto, en el caso del servidor que me ha servido como referencia tiene problemas de acceso a disco y paginación:

El próximo de rendimientos, Windows Server 2008.

Este artículo se lo dedico a mi compañero Sergio, el Rey de los contadores de rendimiento.

Nos vemos.