sábado, agosto 04, 2007

Perfomance: Exchange

Aunque hay varias herramientas que podemos usar para medir el perfomance de exchange, tales como Load Simulator (LoadSim), Exchange Stress and Performance (ESP) 2003, Network Monitor, Filemon, etc, nos enfocaremos hoy solo en Perfomance Monitor (Perfmon) como una continuacion del ciclo.

La recomendacion de tiempo seria al menos tomar un dia, donde se presente ojala el problema o sitacion que queremos analizar, con intervalos de 5 minutos, tambien se puede hacer un monitoreo online con mustras cada 30 segundos, para ver que esta ocurriendo en cada momento con nuestra maquina, en particular con las colas.

Es importante conocer los periodos de mantenimiento del server, por ejemplo cuando se realiza el respaldo o las defragmentaciones online ya que esto tambien se vera reflejado en las muestras.

Contadores para las colas

SMTP Server\Local Queue Length
Indica el numero de mensajes esperado ser distribuido localmente, si este numero comienza a aumentar estamos frente a un problema con nuestra abase de datos local, este numero no debe sobrepasar los 1000 mensajes, la cola debiera mantenerse en un promedio bajo sin muchas variaciones.

SMTP Server\Remote Queue Length

Indica en numero de mensajes esperando se distribuido hacia otros servidores, si este numero crece se debe a problemas de comunicaciones con el o los servidores donde esta el destino del correo, esta cola no debe sobrepasar los 1000 mensajes y debe mantenerse en un numeros promedio que no varia demasiado.

SMTP Server\Categorizer Queue Length

Es el numero de mensajes en la cola smtp para busqueda de atributos en el active directory, este valor debe ser muy pequeño, ojala siempre en 0 y no debe sobrepasar los 10.

MSExchangeIS Mailbox\Send(Receive) Queue Size

Indica en numero de mensajes en la cola de envio(recepcion) del mailbox store, estas cola no debe sobre pasar los 500 mensajes.

MSExchangeIS Public\Send(Receive) Queue Size

Igual que el contador anterior, pero relacionado con las carpetas publicas, de la misma manera, esta cola no debe sobrepasar los 500 mensajes.

Requerimientos RPC

Cuando se usa outlook en modo MAPI, se produce una "traduccion" a RPC (Remote procedure calls) entre el cliente y el servidor, si el usuario esta online, estas llamadas ocurren sincronicamente. Cualquier demora en el server para responder a estos requerimientos afectan directamente al usuarios con una percepcion de lentitud o servicio degradado.

Si el usuario esta en modo cache, esta conversacion es principalmente asincronica, esto se traduce que si hay lentitud en la respuesta esta no es sentida en una lentitud al usuario, no se tiene esa sensacion de que se "pego" el outlook.

Los contadores que nos pueden ayudar a identificar estas demoras (delay) son los siguientes:

MSExchangeIS\RPC Requests
Indica el numero de requerimientos MAPI RPC que estan siendo atendidos por el Information Store, el Information Store solo puede atender hasta 100 de estos requerimientos antes de comenzar a rechazar las conexiones, este numero no debiera soprepasar los 30.

MSExchangeIS\RPC Averaged Latency
Indica la latencia promedio en milisegundos de los ultimos 1024 paquetes, este numero no debiera sobreparasar los 50ms.

Eproxy

EProxy (ExIPC) es un mecanismo de memoria compartida que habilita el proceso de comunicacion entre el IIS (inetinfo) y Exchange Information Store (IS), esta comunicacion es bidireccional la cual atiende protocolos tales como WebDav, IMAP4, POP3, NNTP y SMTP. Esta memoria tambien es usada por DSAccess, el componente de exchange que interactua con Active Directory.

Los contadores que nos sirven para ver este componente son:

Epoxy\Client Out Queue Length (WebDAV)
Indica el numero de mensajes conteniendo mensajes WebDAV en la cola enviados por inetinfo, esta cola no debiera ser mayor a 10.

Epoxy\Store Out Queue Length (WebDAV)
Indica el numero de mensajes conteniendo mensajes WebDAV ern la cola enviados por IS, esta cola tampoco debe sobrepasar los 10 mensajes.

Epoxy\Client Out Queue Length (DSAccess)
Indica el numero de mensajes conteniendo mensajes DSAccess en la cola enviados por inetinfo, esta cola no debe sobrepasar los 10 mensajes.

Epoxy\Store Out Queue Length (DSAccess)
Indica el numero de mensajes conteniendo mensajes DSAccess en la cola enviados por IS, esta cola no debe sobrepasar los 10 mensajes.

Estos contadores tambien estan disponibles para IMAP4, POP3, NNTP y SMTP, para NNTP no debiera sobrepasar los 10 mensajes, para IMAP4, POP3 y SMTP no debe pasar los 50

Procesador

Los analisis que hicimos en el articulo sobre perfomance del procesador con que iniciamos este ciclo siguen siendo validas para Exchange, para este caso, debemos poner especial cuidado en los siguientes tambien:

Process(STORE)\% Processor Time
Process(inetinfo)\% Processor Time
Process(EMSMTA)\% Processor Time
Process(System)\% Processor Time

Estos contadores pueden si usan por ejemplo el de 0 a 100% de 4 CPU mostraran un valor entre 0 y 400%

Si otros procesos son tambien grandes consumidores de CPU en el server, debemos incluirlos tambien en el analisis, estos pueden ser por ejemplo el antivirus.

Memoria

Los indicadores de memoria que analizamos anteriormente tambien son utiles para ver el comportamiento de nuestro servidor, en particular para Exchange, el componente mas comsumidos es IS, por lo que debemos analizar el siguiente contador:

Process(process name)\Private Bytes

Database\Database Cache Size

Cabe hacer notar que Exchange intentara consumir toda la memoria disponible.

Es bueno mencionar en este punto el uso de 2 optimizaciones a nivel del archivo boot.ini, les recomiendo revisar los siguientes articulos respecto a los parametros /3GB y /userva:

823440, "Use of the /3GB switch in Exchange Server 2003 on a Windows Server 2003-based system" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=823440)

316739, "How to use the /userva switch with the /3GB switch to tune the User-mode space to a value between 2 GB and 3 GB" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=316739)

Red

Para analizar que esta ocurriendo a nivel de red, revisemos lo mismos contadores que mencionamos anteriormente.

Disco

Antes de pasar a revisar los contadores de Disco en particular para Exchange, es bueno tener presente lo que ya habiamos revisado.

Para el disco de temporales, debemos considerar los siguientes contadores:

PhysicalDisk\Average Disk sec/Read (Write)
Los valores no deben ser en promedio mayores a 10 con peak no mayores de 50.

PhysicalDisk\Average Disk Queue Length

El promedio debiera ser menor al numero de discos fisicos, 1 si es solo un disco.

Para el disco de la Base de datos (archivos edb y stm)usaremos los siguientes criterios:

PhysicalDisk\Average Disk sec/Read (Write)
Los valores no deben ser en promedio mayores a 20 con peak no mayores de 50.

Database\Database Page Fault Stalls/sec
Indica la tasa de paginas que no pudieron ser entregadas por que no estaban disponibles en el cache de la base de datos, este contador debiera ser 0 en servidores de produccion.

Para el dosco donde se encuentran los transaction logs los criterios debieran ser los siguientes:

PhysicalDisk\Average Disk sec/Read (Write)

Los valores no deben ser en promedio mayores a 5(read)/10(Write) con peak no mayores de 50.

Database\Log Record Stalls/sec

Indica el numero de registros de logs que no pudieron agregarse al buffer de log por segundo por que el log estaba lleno, este valor no debiera ser mayor a 10 por segundo en promedio y los peaks no debieran ser mayores a 100

Database\Log Threads Waiting

Indica el numero de hebras esperando a completar una actualizacion de la base de datos para escribir su dato en un log. si este numero es muy grande estamos frente a cuello de botella provocado por el log, el promedio no debiera ser mayor a 10 hebras.

Para el disco donde se encuentran las colas SMTP

PhysicalDisk\Average Disk sec/Read (Write)
Los valores no deben ser en promedio mayores a 10 con peak no mayores de 50.

Archivo de Paginacion

Ya analizamos el archivo de paginacion anteriormente indicando los valores a considerar para un servidor Exchange.

Espero este articulo les sirva, al igual que los anteriores y espero en una proxima oportunidad profundizar un poco mas en los contadores para problemas mas especificos.

Saludos!

Isa

4 comentarios:

kiyoshi dijo...

isa!!!
bueno, supongo que si eres la misma isa que mmm. tenian una VAX? si.. ya siglos de eso... o era un VM/SP? de tiempos cuando teniamos cuentas con el itesm, en san luis potosi, mexico, el operador master era gilberto..y yo le ayudaba(kiyoshi)
bueno.. solo saludaba... :) kiyo_ueda@yahoo.com

Isabel de la Barra dijo...

Buenas!!!!!!

Que rico saber que aun me recuerdan por esos rumbos, jejeje, por ahi debo tener las fotos que intercambiamos en esos tiempos los que chateabamos por RELAY.

Como no me voy a acordar de ustedes!

Te mande un correo :P

Mdelavega dijo...

Isa.....eres la Isa que trabajaba en Lan?....yo te recuerdo bien, soy del equipo de Peru que trabajo con Rodvic Alvarado, soy Marco de la Vega, ojala te acuerdes....y saludos, (solo en caso de homonimia.....sorry)!!

Isabel de la Barra dijo...

Este post ha sido de los reencuentros!! jejeje
por supuesto que soy la misma!

Saludos a todos los chicos del equipo en Peru!!!