la visión de un ingeniero de campo

Llamar o no a GC.Collect directamente

pmackay — Sun, 22 Feb 2009 16:22:00 GMT

Hace ya un tiempo publiqué un post donde hablaba de liberación de memoria en código manejado, y cómo ayudar a quién es nuevo en .net y le dijeron que la memoria se liberaba sola. En éste, hacía una aclaración, la cual sigo manteniendo hasta ahora. Esta dice relación con el llamar o no a el metodo collect del garbage collector (GC.Collect()).

En esa oportunidad decía que uno jamás debería llamar al recolector de memoria manualmente, sino dejar que la recolección se hiciera en su tiempo, permitiendo que el garbage collector se adiestre sólo. También abría la posibilidad de que alguien diera una buena justificación para hacerlo. Hasta el día de hoy no había dado con ninguna, hasta ahora. Hago hincapié en que no me creo ni soy dueño de la verdad, pero me baso en lo que veo y leo día a día.

Podcast

Estando suscrito a podcasts, rss y cuanta información podamos y creamos que vamos a ser capaces de digerir en algún momento, algunos fueron recibiendo polvo hasta que un largo viaje arriba de un avión me permitió escucharlos, en mi Zune :). Si, tengo un Zune, igual que muy poca gente en este mundo porque nadie la conoce. Bueno, volvamos al grano.

El podcast pertenece a la serie de arcast.tv, el título de éste no era muy atractivo, no así la descripción.

El título decía "Steve Michelotti of e.imagination on High Performance Web Solutions". Al igual que muchos, tu seguramente habrás encontrado documentación o podcasts con títulos impresionantes, que terminaban siendo una recopilación de recomendaciones que puedes encontrar en cualquier buscador, utilizando tres palabras como web, performance y .net.

La descripción por otra parte, detallaba con lujo de que se trataba. El tema principal era problemas con el recolector de basura en arquitecturas de 64 bits. No voy a incluir acá la descripción porque no podría justificar el contenido de lo que escribiré ahora y perdería la gracia.

Si el inglés no te abandona, te recomiendo que veas el podcast, como otros también en el mismo sitio. El de RESTful services está muy bueno, al menos para los que creemos en REST y sus cualidades. Si ves el podcast, puedes evitar seguir leyendo ésto.

¿Entonces?

Si no vas a ver el podcast y sigues acá, te cuento de qué se trata. No haré una traducción literal porque no tendría sentido, sino algo donde explique los puntos y complemente la información.

Mencionaba hace un rato que el garbage collector se adiestra automáticamente de acuerdo al patrón de petición de memoria de tu aplicación (allocation pattern en inglés). Para el caso de el sitio mencionado, varios problemas sacudían el día a día, todos relacionados con la petición y liberación de memoria. Veamos cada uno punto a punto y cómo los fueron tratando.

Gran cantidad de objetos creados en memoria

La aplicación era capaz de crear miles, millones de objetos en breve tiempo, los cuales eran descartados una vez que se dejaban de usar. Esto, en general, es esperable en cualquier aplicación. Los objetos se crean, se usan y luego se le dejan al GC para que reclame la memoria. El problema de ellos es que creaban muchos, MUCHOS objetos, aumentando la administración de memoria y disparando la recolección de basura con una frecuencia más breve. Si no haz visto el post de adiestramiento del GC, te lo recomiendo para clarificar este punto.

¿Cómo mitigaron el problema?, fácil, o ni tanto. Reutilizando objetos en vez de dejárselos al GC para que liberara la memoria utilizada. Debo reconocer que cuando lo escuchaba, me costaba asumir que era una opción que alguna vez podría considerar debido a la cantidad de trabajo que involucra. De esta forma, se crean menos objetos y se destruyen menos. Por lo tanto, menos presión al GC.

¿Cuál es el problema con el GC?

Mmm, en teoría, ninguno. En la práctica, debido a que el espacio de memoria virtual de un proceso de 64 bits es muy grande, en dónde grande significa aproximadamente 8TB de espacio de memoria virtual en modo usuario y 8TB en modo kernel (con diferencias leves entre IA64 y x64), los bloques de memoria manejados por el garbage collector pueden ser muchos más que en una arquitectura de 32 bits, donde los espacios de memoria eran 2GB para usuario y 2GB para kernel.

Como los bloques son muchos más , para el caso de la aplicación en cuestión, si el GC debía hacer una recoleción completa, es decir, incluir las 3 generaciones y el heap de objetos grandes (Large Object Heap o LOH en inglés), esta podía tomar entre 5 y 8 segundos en completarse. Para recolecciones de la generación 0 y 1, no es un problema porque ambas generaciones estan un único segmento, que por lo general no supera los 64 MBs.

Es importante rescatar que mientras se realiza una recolección de memoria, todos los hilos que están ejecutando código manejado son detenidos. Esto impactaba sevéramente en el SLA (Contrato de nivel servicio) de ellos. Si cada cierto tiempo se debe "detener" un servidor entre 5 y 8 segundos, será dificil poder cumplir con un SLA de 99,99%.

Otras acciones

Entonces, a la reutilización de objetos mencionada, se le agregó además la verificación que tanto operaciones de boxing como unboxing fuesen mínimas en el código. Boxing y unboxing se refieren a convertir un objeto de un tipo específico (de tipo valor) al tipo object y viceversa. Esto ocurre generalmente fuera de nuestra vista, cuando utilizamos funciones o tipos que reciben object en vez del tipo específico. En el siguiente post se muestra cómo detectar y minimizar este patrón de uso.

Otra acción para minimizar el problema del consumo de memoria, fue utilizare object pooling, funcionalidad generalmente utilizada para mantener conexiones a la base de datos sin ser destruidas, con el fin de minimizar la creación y destrucción de los objetos, proceso que ya sabemos es costoso.

¿Dónde entra GC.Collect y el llamado de forma explícita?

Habiendo minimizado la creación y destrucción de objetos, el problema continuaba ocurriendo en menor medida, pero cuando ocurría, nuevamente se sufría de varios segundos sin servicio.

Implementaron entonces un mecanismo de broadcasting para la aplicación, con el que se informaba del estado de un servidor, a todas las aplicaciones corriendo en los servidores que componían la capa de aplicación.

Cada cierto período de tiempo, y cuando ya "se creía" que podría ocurrir una recolección de memoria completa en una aplicación del servidor X, ésta le avisaba a todas las aplicaciones de los servidores restantes que iba a recolectar basura, y que por lo tanto no le fueran enviados requerimientos. Luego, cuando estaba "fuera de línea", llamaba manualmente a GC.Collect y una vez finalizada la recolección, avisaba a las otras aplicaciones que ya estaba "en línea".

Si bien la solución ayuda a mitigar el problema, se basa en la creencia (y esperanza) de que pronto será recolectada la memoria, esto, con el fin de actuar antes y evitar el impacto de quedar fuera por varios segundos. Sin embargo, ya sabemos que la recolección ocurre de forma no deterministica. Sólo el GC sabe cuándo será recolectada la memoria... hasta ahora.

... Hasta ahora ...

La ayuda final que le da el toque de elegancia al modelo de ellos, (que ya lo tenía, para ser justos), vino de la persona que desarrolla el GC (Maoni Stephens). Ella ayudó con la implementación de una funcionalidad que permite, como aplicación, ser notificado con un margen de tiempo especificable por uno, cuándo podría ocurrir la recolección de basura, permitiendoles a ellos no tener que "adivinar" o "creer" cuando ocurrirá la recolección, si no que tener certeza absoluta.

Esta nueva funcionalidad, más la implementación del mecanismo de broadcasting, de puesta y sacada de línea de las aplicaciones, se puede minimizar totalmente el impacto de éstas.

La funcionalidad del GC la pueden ver en el siguiente articulo de MSDN.

Al menos para mí, este es el primer caso donde veo que el llamado de GC.Collect() de forma manual es la solución a algún problema específico.

Saludos,
Patrick

Alto consumo de memoria y cursores de datos

pmackay — Thu, 20 Mar 2008 21:22:00 GMT

Sorpresas te llevas en la vida, siempre. A pesar de lo que parezca, hoy no ando sermoneador ni nada por el estilo. Es sólo que no se me ocurre como comenzar este post así que escribo lo primero que se me ocurre . Total, lo interesante viene ahora.

Viaje de emergencia, aplicación ASP con excepciones por falta de memoria (Out Of Memory), servicio interrumpido.
Resumen: problemas... un poco de entretención para unos meses muy aburridos.

Síntomas

Como mencionaba, tenemos una aplicación ASP que de vez en cuando lanza excepciones por falta de memoria, mas conocidos como error 500 ASP 147. Obviamente con el reinicio del proceso, todo vuelve a la normalidad, pero luego de la calma, llega la tormenta.

Como ya es costumbre, se capturaron algunos dumps de memoria cuando se estaba produciendo el error y se analizaron. Los resultados fueron sorprendentes, los que pasan a ser mostrados ahora.

Lo primero muy interesante es que el dump apenas sobrepasaba los 100 megabytes. Un dump contiene, sin entrar en grandes detalles, los datos privados del proceso y las librerías cargadas entre otras cosas. Si son un poco más de 100 megabytes, ¿cómo es posible que haya falta de memoria?. El administrador de tareas confirmaba que el proceso estaba utilizando algo más de 100 megabytes en working set y un poco menos en memoria privada

¿Entonces?

Debugging Tool For Windows entra a ayudarnos. Revisando el estado de cada heap, nos encontramos con lo que muestra el bloque de más abajo. Hay muchas columnas y muchos datos, pero fijemos la atención en las columnas que hacen mención a la memoria reservada y comprometida.

Recordemos que en un sistema operativo Windows, la memoria puede estar en tres estados: libre, reservada y comprometida. Para que una aplicación la pueda utilizar necesita primero reservarla, y luego comprometerla. Después de usarla, la debe des-comprometer (fea palabra, lo sé) y luego liberar (des-reservar, también es fea).

  Heap     Flags   Reserv  Commit  Virt   Free  List   UCR  Virt  Lock  Fast 
                    (k)     (k)    (k)     (k) length      blocks cont. heap 
-----------------------------------------------------------------------------
00080000 00000002   15360  13424  14512   2362   514   137    0     9d   L  
    External fragmentation  17 % (514 free blocks)
00180000 00008000      64     12     12     10     1     1    0      0      
002b0000 00001002   22080   9560  17536   1629   231   124   25     5b   L  
    External fragmentation  17 % (231 free blocks)
    Virtual address fragmentation  45 % (124 uncommited ranges)
00550000 00000002    1024     20     20      2     1     1    0      0   L  
00690000 00001002     256     32     32      2     1     1    0      0   L  
01bb0000 00001002     256     12     12      4     1     1    0      0   L  
01bf0000 00001002   39872  11200  29608    722    62    60    0      7   LFH
01c30000 00001002     256     12     12      4     1     1    0      0   L  
01c70000 00001002     256     12     12      4     1     1    0      0   L  
<recortado>
02630000 00001002     256     12     12      2     1     1    0      0   L  
02670000 00001002     256     12     12      4     1     1    0      0   L  
02730000 00001002      64     32     32      4     1     1    0      0   L  
02a20000 00001002    3328   2084   2396    110    23    16    0      0   LFH
02a60000 00001002   19968   7164   8076     35     6    10   21      0   LFH
02f60000 00001003    1280   1152   1152      2     1     1    0    bad      
03470000 00001003    1280    512    512      1     1     1    0    bad      
034b0000 00001003    1280    524    524      2     1     1    0    bad      
034f0000 00001003     256     96     96      0     0     1    0    bad      
03730000 00001003    1280    356    356      1     1     1    0    bad      
03970000 00001003    1280    264    264      0     0     1    0    bad      
049b0000 00001003     256    204    204      3     1     1    0    bad      
049f0000 00001003  130304    128    300     63    11    12    0    bad      
04a30000 00001003  441600    112    188    101    11    12    0    bad  <-éste
04a70000 00001003  167204    352    424    264    49    67    0    bad      
04ab0000 00001003  465716    128  36532    103    20    27    0    bad      
04af0000 00001003  469708    164   1696     92    13    32    0    bad      
04b30000 00001003   46312    324    328    254    47    65    0    bad      
04b70000 00001003    9700    372    372    348    62    64    0    bad      
039c0000 00001002      64     16     16      2     1     1    0      0   L  
04c30000 00001003     256    148    148     92    36     1    0    bad      
<recortado>

En el listado anterior, vemos que hay un par de heaps que han reservado (memoria en estado reservado) más de 400 megabytes, pero que sólo están utilizando (memoria en estado comprometido) un poco más de 100 kilobytes. Entre varios, el heap 04a30000, indicado más arriba en negrilla y con la palabra "<- éste", es uno de los más grandes.

Veamos el detalle de este heap y sus segmentos, listados a continuación.

Index   Address  Name      Debugging options enabled
111:   04a30000 
    Segment at 04a30000 to 04a70000 (00010000 bytes committed)
    Segment at 0f940000 to 0fa40000 (00003000 bytes committed)
    Segment at 0fa40000 to 0fc40000 (00001000 bytes committed)
    Segment at 100d0000 to 104d0000 (00001000 bytes committed)
    Segment at 104d0000 to 10cd0000 (00001000 bytes committed)
    Segment at 10cd0000 to 11cd0000 (00001000 bytes committed)
    Segment at 11cd0000 to 13cd0000 (00001000 bytes committed)
    Segment at 13cd0000 to 17cd0000 (00001000 bytes committed)
    Segment at 17ed0000 to 1fed0000 (00001000 bytes committed)
    Segment at 4dbd0000 to 55bd0000 (00001000 bytes committed)
    Segment at 5bb60000 to 5eb60000 (00001000 bytes committed)

Mmm... mmm...mmm...mmm (esto me recuerda una canción de hace unos años), la mayoría de ellos no tiene más de 4 kilobytes usados para bloques de varios megabytes reservados. Si las matemáticas no te ayudan ahora, 1000 en hexadecimal es equivalente a 4096 en decimal.

Análisis de la situación

Recordemos que el manejo de la memoria lo realiza generalmente el sistema operativo aunque algunas aplicaciones pueden utilizar sus propios manejadores de memoria. Desde código ASP (VBScript) o Visual Basic 6.0, como también desde código manejado NO es posible trabajar a este nivel con la memoria. Lo anterior es un problema en un manejador de memoria.

Si no es ASP, VB. 6.0, ¿qué puede ser? (considerando que no hay componentes desarrollados por el cliente en C o C++)

La respuesta la da Debug Diagnostics. Quien creo el heap es "Microsoft Data Access Runtime", es decir, MDAC. Revisando la versión instalada, comprobamos que es la última con Windows Server 2003 SP2. El camino se pone difícil.

Investigación y resolución

Involucrando a las personas adecuadas, aprendimos que este comportamiento es considerado "esperado" cuando se cumplen las siguientes condiciones:

Se utilizan recordset del lado del cliente (client-side cursor)
Se obtienen muchos datos, muchos datos de una tabla

Ok ¿client-side cursor?¿que significa "muchos datos"?

"Cliente" es quien consulta la base de datos, que para este caso es IIS/ASP. En ese caso, los datos se llevan al cliente para ser luego procesados.

Después de investigar en el código, se encontró que una consulta estaba retornando más de 2 millones de registros. Eso es mucho

Reproducción

Decidido a demostrarlo, procedí a hacer unas pruebas con el siguiente código en mi "servidor."

Y le agregué a mi tabla algo así como 4 millones de registros.

Después de varias ejecuciones, tanto en paralelo como en serie, los contadores de memoria reservada, comprometida y utilización de procesador mostraron esto:

Se puede ver que la memoria comprometida (verde) llegó como mucho hasta 300 megabytes, pero la memoria reservada (roja) aumentó sin mostrar intención de disminuir, llegando casi hasta 900 megabytes.

¿Cuál es la explicación a que no reutilice la memoria reservada y siga reservando más? Al menos yo no tengo la respuesta.

¿Que sucede cuando llegue a 2 gigabytes? excepciones por falta de memoria (Out Of Memory)

Conclusiones

1.- Nunca desplegar "muchos" registros en una página. Mejor aún, nunca pedir muchos registros a la base de datos.

2.- Utilicen server-side cursors. Hagan la prueba con el mismo código y comparen los resultados.

Saludos,
Patrick

Internet Explorer se cuelga por algunos segundos

pmackay — Thu, 10 Jan 2008 09:15:00 GMT

A diferencia de los otros casos descritos, en esta oportunidad quien estaba en problemas era yo mismo, con un síntoma que seguro a alguno de ustedes le ha ocurrido antes. Veamos de que se trata.

Síntomas

Cada vez que abría una nueva instancia de Internet Explorer, como también al abrir una nueva pestaña de una instancia que ya llevase corriendo, algunas veces se demoraba una buena cantidad de segundos (entre 10 y 15 segundos) en quedar disponible para poder usarla. Si bien el proceso se creaba y se pintaba rápidamente (menos de 1 segundo), quedaba como "esperando" algo.

Esta es una ventana del navegador en ese estado intermedio de espera.

Una vez que la espera termina, el navegador funciona como se espera. Sin embargo, si se deja pasar un tiempo sin hacer nada en la ventana de éste, al tratar de usarlo nuevamente, ya sea creando un tabulador nuevo o incluso cerrando el proceso, otra vez debo esperar una cantidad de segundos similar a la anterior.

En resumen, mientras esté usando la ventana (haciendo clics), todo bien. Dejo de usarla un rato, hay que esperar para que reaccione.

Intención de detección del problema

Aunque sabía que no sería nada fácil encontrar el problema, hice mi intento usando Debugging Tool For Windows y atachándome al proceso una vez creara un nuevo tab mientras estaba "esperando".

Un listado de los threads relevantes (0 y 5) y sus stacks correspondientes en el momento de espera mostraba lo siguiente.

   0  Id: 12f0.123c Suspend: 1 Teb: 7efdd000 Unfrozen
ChildEBP RetAddr  
002ce690 7d4e286c ntdll!NtWaitForMultipleObjects+0x15
002ce738 7d94d299 kernel32!WaitForMultipleObjectsEx+0x11a
002ce794 02596029 user32!RealMsgWaitForMultipleObjectsEx+0x152
002ce7b4 0259632d ieui!CoreSC::Wait+0x49
002ce7dc 025960d8 ieui!CoreSC::WaitMessage+0x54
002ce7e8 4640994d ieui!WaitMessageEx+0x33
002ce818 463fabcc ieframe!CBrowserFrame::FrameMessagePump+0x199
002ce824 463fbc3b ieframe!BrowserThreadProc+0x3f
002ce848 463fbb89 ieframe!BrowserNewThreadProc+0x7b
002cf8b8 463fba39 ieframe!SHOpenFolderWindow+0x188
002cfae8 00401464 ieframe!IEWinMain+0x2d9
002cff2c 004012ff iexplore!wWinMain+0x2c1
002cffc0 7d4e7d2a iexplore!_initterm_e+0x1b1
002cfff0 00000000 kernel32!BaseProcessStart+0x28

   5  Id: 12f0.12e8 Suspend: 1 Teb: 7efa9000 Unfrozen
ChildEBP RetAddr  
02fee038 7d4d8c82 ntdll!ZwWaitForSingleObject+0x15
02fee0a8 7da3936a kernel32!WaitForSingleObjectEx+0xac
02fee0c4 7da3ba11 rpcrt4!UTIL_WaitForSyncIO+0x20
02fee0e8 7da3b9eb rpcrt4!UTIL_GetOverlappedResultEx+0x1d
02fee104 7da3b9a9 rpcrt4!UTIL_GetOverlappedResult+0x17
02fee124 7da3ad05 rpcrt4!NMP_SyncSendRecv+0x73
02fee14c 7da3af2d rpcrt4!OSF_CCONNECTION::TransSendReceive+0x7d
02fee1d4 7da3aea2 rpcrt4!OSF_CCONNECTION::SendFragment+0x2ae
02fee22c 7da3b1b9 rpcrt4!OSF_CCALL::SendNextFragment+0x1e2
02fee274 7da3b834 rpcrt4!OSF_CCALL::FastSendReceive+0x148
02fee290 7da3b7b7 rpcrt4!OSF_CCALL::SendReceiveHelper+0x5b
02fee2c0 7da37d3e rpcrt4!OSF_CCALL::SendReceive+0x41
02fee2cc 7da37cf0 rpcrt4!I_RpcSendReceive+0x24
02fee2e0 7dac01b6 rpcrt4!NdrSendReceive+0x2b
02fee6c8 71c4b685 rpcrt4!NdrClientCall2+0x22e
02fee6e0 71c4b644 netapi32!NetrLogonGetTrustRid+0x1c
02fee720 7da4af08 netapi32!I_NetlogonGetTrustRid+0x1e
02fee768 7da4ae60 rpcrt4!GetMachineAccountSid+0xcb
02fee780 7da3f97e rpcrt4!NormalizeAccountSid+0x4c
02fee88c 7da4aaa4 rpcrt4!LRPC_CASSOCIATION::OpenLpcPort+0x1e9
02feeb88 7da4a40b rpcrt4!LRPC_CASSOCIATION::CreateBackConnection+0x74
02feebc4 7da456fb rpcrt4!LRPC_CASSOCIATION::ActuallyDoBinding+0x32
02feec3c 7da3843a rpcrt4!LRPC_CASSOCIATION::AllocateCCall+0x190
02feec70 7da38366 rpcrt4!LRPC_BINDING_HANDLE::AllocateCCall+0x1f2
02feec9c 7da37a1c rpcrt4!LRPC_BINDING_HANDLE::NegotiateTransferSyntax+0xd3
02feecb4 7778c956 rpcrt4!I_RpcGetBufferWithObject+0x5b
02feecf8 7778c629 ole32!CRpcChannelBuffer::ClientGetBuffer+0x31c
02feed08 776c0e9e ole32!CRpcChannelBuffer::GetBuffer+0x20
02feed28 776c0f7a ole32!CAptRpcChnl::GetBuffer+0x209
02feed8c 7dac0fda ole32!CCtxComChnl::GetBuffer+0x1e5
02feeda8 7dac0f89 rpcrt4!NdrProxyGetBuffer+0x47
02fef190 776a3717 rpcrt4!NdrClientCall2+0x173
02fef1a8 7778b6e4 ole32!IClassFactory_RemoteCreateInstance_Proxy+0x1c
02fef1c4 776ad8ac ole32!IClassFactory_CreateInstance_Proxy+0x41
02fef24c 776aaf7e ole32!CServerContextActivator::CreateInstance+0x175
02fef28c 776ad9b6 ole32!ActivationPropertiesIn::DelegateCreateInstance+0xf7
02fef2e0 776ad92d ole32!CApartmentActivator::CreateInstance+0x110
02fef300 776acb27 ole32!CProcessActivator::CCICallback+0x6d
02fef320 776acad8 ole32!CProcessActivator::AttemptActivation+0x2c
02fef35c 776ada17 ole32!CProcessActivator::ActivateByContext+0x4f
02fef384 776aaf7e ole32!CProcessActivator::CreateInstance+0x49
02fef3c4 776aaf19 ole32!ActivationPropertiesIn::DelegateCreateInstance+0xf7
02fef614 776aaf7e ole32!CClientContextActivator::CreateInstance+0x8f
02fef654 776ab10f ole32!ActivationPropertiesIn::DelegateCreateInstance+0xf7
02fefe08 776a679a ole32!ICoCreateInstanceEx+0x3f8
02fefe3c 776a6762 ole32!CComActivator::DoCreateInstance+0x6a
02fefe60 776a6963 ole32!CoCreateInstanceEx+0x23
02fefe90 4635a747 ole32!CoCreateInstance+0x3c
02fefec0 4638f691 ieframe!SHCoCreateInstanceAC+0x9e
02feff08 463c167a ieframe!WinList_RegisterPending+0x2c
02feff4c 463ee4b9 ieframe!CTabWindow::_RegisterPendingWindow+0x149
02feffb8 7d4dfe21 ieframe!CTabWindow::_TabWindowThreadProc+0x99
02feffec 00000000 kernel32!BaseThreadStart+0x34

El thread 0 es el thread principal y aparentemente no está haciendo mucho, salvo esperar que el kernel le avise que ciertos eventos han ocurrido.

Sin embargo, el thread 5 sí está haciendo algo y es exactamente lo que yo le había pedido. Crear un tabulador. Esto lo puedo inferir por las llamadas a las funciones con nombres acordes, como se puede apreciar ahora

<cortado ...>
02feff4c 463ee4b9 ieframe!CTabWindow::_RegisterPendingWindow+0x149
02feffb8 7d4dfe21 ieframe!CTabWindow::_TabWindowThreadProc+0x99
02feffec 00000000 kernel32!BaseThreadStart+0x34

Ok, tenemos el thread que crea el tabulador. ¿qué más?

Mirando el stack, se puede observar creación de objetos COM, posiblemente una creación de contexto de COM o una reutilización de uno existente (no estoy del todo seguro de cual opción), una llamada RPC, interacción con el sub-sistema de Windows (kernel32.dll) y el kernel (ntdll.dll).

A diferencia de una revisión de aplicaciones como asp.net o asp tradicional, donde uno espera encontrar código del cliente que no está optimizado y que consume recursos, en esta oportunidad no había código de terceros. El camino se veía difícil.

Golpes de suerte

Con dos sucesivos golpes de suerte logré dar con el problema, pero jamás podría haberlo detectado sin un post de Mark Russinovich, donde él experimentó un problema similar. El primer golpe de suerte fue elegir alguna función que pareciese sospechosa y luego, livear en internet. La función elegida fue GetMachineAccountSid y la búsqueda retornó este post en primera opción.

http://blogs.technet.com/markrussinovich/archive/2006/08/31/453100.aspx
The Case of the Process Startup Delays

Con ese título del post, claramente estábamos enfrentando el mismo problema. Eso sí, la diferencia es que Mark sabe reconocer el problema, pero uno debe apelar a la suerte y a los buscadores de internet.

Haciendo pruebas similares a las del post mencionado, obtuve respuestas similares.

Bien. Traté de atacharme a lsass.exe (local security authority subsystem) con nefastos resultados. Una vez atachado windbg a lsass, hice una mala maniobra y windbg dejó de responder, haciendo que el sistema quedase medianamente bloqueado (respondía muy lento) ya que muchos procesos depende de lsass.exe. Como no hubo más opción que matar windbg, esto traería como consecuencia que el proceso que se estaba debugueando también moriría. Y si muere lsass.exe, el sistema operativo te pide amablemente reiniciar, con una pantalla similar a la pantalla del virus que atacaba XP antes de SP2 y que te daba 48 segundos para cerrar todo.

La consecuencia.

Como dirían en algunos programas de televisión; "niños, no traten de hacer esto en casa," o mejor dicho, no lo hagan mientras visitan a un cliente y deben trabajar con su equipo.

Resolución

A diferencia del post de Mark, en donde el causante del problema era Defender, en este caso no había un tercer involucrado que remover del sistema.

La solución no fue la más elegante, pero no tuve más alternativa que ejecutar Internet Explorer en el contexto de un usuario local de la máquina, para así evitar que se trate de obtener información desde el dominio, el cual no puede ser alcanzado.

Lamentablemente esto trajo como consecuencia que no pudiese accesar a mi historial ni favoritos. Espero que cuando logre conectarme al dominio se acaben los problemas.

Saludos,
Patrick

Signos vitales de un servidor: Parte III (disco)

pmackay — Fri, 04 Jan 2008 03:38:00 GMT

Después de unos días de descanso debido a las fiestas ampliamente conocidas, continuamos con la tercera entrega de la serie de monitoreo de signos vitales de un servidor, en la cual presentaremos la información necesaria para detectar problemas de rendimiento en las unidades lógicas de disco de un servidor.

Si bien es posible determinar problemas en unidades físicas, las diferentes configuraciones físicas de arreglos RAID 0, 1, 5, 1+0 y 0+1 y la creación posterior de unidades lógicas en el arreglo, hace muy difícil, si es que no imposible, el determinar si es o no un disco físico específico.

Antes de comenzar, hago un mini corte para recomendar este link de una presentación de David Solomon sobre cómo maneja la memoria Windows y como hacer un troubleshooting básico de los problemas. Además, se da tiempo de romper algunos mitos. Definitivamente un video imperdible. Está en inglés y dura 1 hora y 37 minutos.

http://www.microsoft.com/uk/technet/itsshowtime/sessionh.aspx?videoid=64

Diferentes caminos

Para la verificación de los contadores de disco, existen dos caminos conocidos. Uno de ellos el difícil y otro mucho más simple y agnóstico del hardware.

El primer camino, el cual NO veremos aquí corresponde a obtener información de los IOs de los discos, calcular la cantidad de operaciones de lectura y escritura que se realizan por cada tipo de RAID, la cantidad de discos físicos (ejes) involucrados en el RAID y hacer una cantidad importantes de cálculos y asumir con poca certeza algunas constantes o valores.

El segundo camino, mucho más simple, es agnóstico del tipo de RAID, la cantidad de discos y otras variables. ¿Qué es lo que mide? muy simple y básico:

¿Cuánto tiempo se demora el sistema de discos en realizar una operación de escritura o lectura?

Si se demora "mucho," hay un problema. Si se demora "poco," estamos bien. Si tienes picos elevados constantes, podemos estar en presencia de algún inconveniente o escasez de capacidad de procesamiento.

Además de la información relacionada con escrituras y lecturas, se debe complementar con información general del disco como el porcentaje de tiempo disponible y largo de la cola de requerimientos.

Veamos los contadores y contra qué compararlos, es decir, que es "bueno" y "malo."

Nota: Antes de comenzar aclaro que cuando digo disco "malo," no estoy mencionando que el disco está malo físicamente o que presenta alguna falla sino que realmente me refiero a que el disco no responde de acuerdo a lo que es espera de él, generalmente producto de una tasa muy elevada de requerimientos.

Contadores

Los contadores a medir del objeto Logical Disk, para la instancia específica (c:, d:, etc.), son los siguientes:

Avg Disk Sec/read: milisegundos en que una operación de lectura es llevada a cabo.
Avg disk Sec/write: milisegundos en que una operación de escritura es llevada a cabo.
% Idle time: porcentaje de tiempo que el disco está desocupado.
Avg disk queue length: largo promedio de la cola de requerimientos del disco
Current disk queue length: largo actual de la cola de requerimientos del disco

¿Contra que los comparamos?

Los dos primeros contadores se comparan contra la misma tabla de valores, la cual despliego a continuación:

Valor medido	Significado
entre 1 milisegundo y 15 milisegundos	Perfecto estado
entre 16 milisegundos y 25 milisegundos	Se debe monitorear
más de 25 milisegundos	Disco degradado

Se deben considerar valores promedios. Es esperable que un disco tenga picos por sobre los 25 milisegundos pero el valor promedio debe ser bajo.

Nota: Si tienes un storage con caché de escritura, deberás ser más estricto en las comparaciones y reducir un poco los valores. Esto se debe a que el caché de escritura mejora sustancialmente el rendimiento. Si antes 15 ms era el tope para considerar el valor como perfecto, entonces si mides 15 ms y tienes caché habilitado, no estarás dentro del grupo de perfecto estado sino que el rendimiento será medio y deberás monitorear la actividad.

Anécdota: El valor más alto que he presenciado en algunos casos ha sido de más de 900 milisegundos. Por supuesto, el servicio que se estaba exponiendo estaba severamente afectado, con tiempos de respuesta muy bajos.

El contador del tiempo porcentaje de tiempo disponible es simple también. Más de 50%, perfecto estado. Entre 20% y 50%, se deberá monitorear y menor a 20%, el disco está degradado.

Por último, para los contadores de largo de cola de requerimientos promedio y actual, estos dos valores se comparan y calculan de la misma forma. Si la cantidad de discos físicos que componen el arreglo de discos es conocida, se deberá comparar contra el valor medido menos la cantidad de discos y dividirlo por dos.

Por ejemplo: Si el valor medido del largo promedio de la cola de requerimientos es 25 y tengo 10 discos en el arreglo, la formula nos retorna: (25-10)/2 = 7,5.

Este valor es menor a 1, el rendimiento es excelente. Entre 1 y 3, se deberá monitorear. Mayor a 3, crítico o degradado.

Por supuesto, la formula presenta inconvenientes cuando los valores medidos son menores a la cantidad de discos, pero en ese caso el disco claramente no tiene problemas.

¿Qué sucede si no conozco la cantidad de discos? y bueno, en ese caso se recomienda dividir por 2 el valor medido en el contador y aplicar la misma regla de comparación. Entendemos que no es un valor fidedigno, pero tampoco es "tan errado." Para el mismo ejemplo, 25/2 es 12,5, un valor mayor a 7,5, pero igual de malo de acuerdo a el parámetro de comparación.

Como pueden ver, monitorear un disco es muy simple. Si no responde en tiempos breves, claramente le estamos pidiendo más de lo que puede dar.

Queda pendiente una o dos entregas más de signos vitales, las que llegarán espero durante este mes.

Saludos,
Patrick

Traza de asp.net y el consumo de memoria

pmackay — Tue, 18 Dec 2007 02:24:00 GMT

El siguiente caso a presentar está relacionado con el alto consumo de memoria de una aplicación. Como el título lo dice, está relacionado con el uso de la traza de asp.net (trace en web.config.)

El escenario era similar a lo descrito ahora. La aplicación analizada empezaba a consumir memoria y aunque tenía momentos donde la liberaba, la impresión general era que en el largo plazo, siempre subía. Este es un típico comportamiento de un memory leak o pérdida de memoria; la tendencia al alza, aunque con momentos donde baja un poco.

Como ya es tradición, un dump del proceso y mi amigo Debugging Tool For Windows nos darían las pistas necesarias. También nos apoyamos en performance monitor, pero hay veces que ya sabes que es una pérdida de memoria y éste no te dirá mucho más de lo que ya sabes.

Con el dump en mis manos, hacemos una revisión del proceso afectado y el estado de la memoria virtual del éste.

Recolección de información general

Tamaño del dump: ~300 MB. No es muy grande, pero tampoco es descartable. Tradicionalmente se espera a que la memoria privada del proceso llegue al menos hasta 500 MB para declararlo como sospechoso.

Información del proceso:

System Uptime: 180 days 15:52:41.140
Process Uptime: 0 days 2:08:23.000
Kernel time: 0 days 0:00:13.000
User time: 0 days 0:08:48.000

El sistema operativo lleva corriendo 180 días sin reiniciarse. El proceso en cuestión lleva del orden de 2 horas y 8 minutos corriendo y que ha consumido 13 segundos en modo privilegiado (kernel) y 8 minutos y 48 segundos en modo usuario.

Con 8 minutos de procesamiento ya llegó a 300 MB. Interesante.

El estado de la memoria virtual concuerda con el tamaño del dump, reflejado gráficamente en la imagen de la derecha, la cual pueden pinchar para agrandar.

Efectivamente hay aproximadamente 300 MB de memoria virtual, de los cuales casi 190 son de memoria manejada.

Memoria manejada

Haciendo una revisión de los heaps del GC, obtenemos la información de la siguiente lista. El servidor tiene 4 procesadores por lo que se crean cuatro heaps del GC, cada uno con sus propias generaciones, heaps efímeros y heaps de objetos grandes.

Number of GC Heaps: 4
------------------------------
Heap 0 (0x000d01c8)
generation 0 starts at 0x121135c8
generation 1 starts at 0x12109a44
generation 2 starts at 0x102d0030
ephemeral segment allocation context: none
segment begin allocated size reserved
0x102d0000 0x102d0030 0x121135d4 0x01e435a4(31,733,156) 0x00d79000
Large object heap starts at 0x202d0030
segment begin allocated size reserved
0x202d0000 0x202d0030 0x205d2168 0x00302138(3,154,232) 0x00cdd000
Heap Size 0x2245770(35,936,112)
------------------------------
Heap 1 (0x000d08d8)
generation 0 starts at 0x16009a28
generation 1 starts at 0x15eaacac
generation 2 starts at 0x142d0030
ephemeral segment allocation context: none
segment begin allocated size reserved
0x142d0000 0x142d0030 0x16009a34 0x01d39a04(30,644,740) 0x014c7000
Large object heap starts at 0x212d0030
segment begin allocated size reserved
0x212d0000 0x212d0030 0x21449a38 0x00179a08(1,546,760) 0x00e66000
Heap Size 0x1f2b4a0(32,683,168)
------------------------------
Heap 2 (0x000d13d8)
generation 0 starts at 0x24461404
generation 1 starts at 0x243e6e2c
generation 2 starts at 0x182d0030
ephemeral segment allocation context: none
segment begin allocated size reserved
0x182d0000 0x182d0030 0x1998c7dc 0x016bc7ac(23,840,684) 0x028ef000
0x242d0000 0x242d0030 0x24461410 0x001913e0(1,643,488) 0x033c4000
Large object heap starts at 0x2a2d0030
segment begin allocated size reserved
0x2a2d0000 0x2a2d0030 0x2a2d0030 0x00000000(0) 0x047df000
Heap Size 0x198fb8c(26,803,084)
------------------------------
Heap 3 (0x000d1ca0)
generation 0 starts at 0x087954cc
generation 1 starts at 0x083dd820
generation 2 starts at 0x1c2d0030
ephemeral segment allocation context: none
segment begin allocated size reserved
0x1c2d0000 0x1c2d0030 0x1df48b8c 0x01c78b5c(29,854,556) 0x02310000
0x08330000 0x08330030 0x087954d8 0x004654a8(4,609,192) 0x01fff000
Large object heap starts at 0x232d0030
segment begin allocated size reserved
0x232d0000 0x232d0030 0x2344ed50 0x0017ed20(1,568,032) 0x00e61000
0x0edc0000 0x0edc0030 0x0f195f40 0x003d5f10(4,022,032) 0x00c2a000
Heap Size 0x277ac50(41,397,328)
------------------------------
Reserved segments:
------------------------------
GC Heap Size 0x827b3ec(136,819,692)

De esta información se puede ver que hay muchos objetos en generación 2, lo que significa que hay objetos que no se han liberado y han ido envejeciendo más de lo necesario.

¿Qué hay en la memoria?

Haciendo un vaciado estadístico de los objetos, utilizando Debugging Tool For Windows y sos, obtenemos un listado como el de a continuación, donde se ha eliminado parte del comienzo y sólo se ha dejado el final, que contiene la información relevante para el caso.

MT Count TotalSize Class Name
.....<recortado por el bien de esta página>...
0x028665f0 22,807 273,684 System.Xml.Xsl.EndEvent
0x02784adc 14,800 296,000 System.Data.DataRowCollection
0x027844dc 14,800 296,000 System.Data.DataRowBuilder
0x027862d4 14,911 298,220 System.Data.ColumnQueue
0x02782a74 11,824 331,072 System.ComponentModel.CollectionChangeEventHandler
0x0230159c 14,866 356,784 System.Xml.NameTable/Entry
0x02925aec 7,847 408,044 System.Xml.Xsl.XsltCompileContext
0x02926bfc 11,589 417,204 System.Xml.XPath.XPathChildIterator
0x02863d04 8,692 417,216 System.Xml.XPath.ChildrenQuery
0x027846d4 14,800 473,600 System.Data.RecordManager
0x0278001c 14,800 473,600 System.Data.ConstraintCollection
0x027842e4 14,913 477,216 System.ComponentModel.PropertyDescriptorCollection
0x0280cddc 16,754 670,160 System.Xml.XPath.XPathWhitespace
0x0280c924 10,044 682,992 System.Xml.XPath.XPathElement
0x02866564 22,807 729,824 System.Xml.Xsl.BeginEvent
0x0252ebe4 14,800 769,600 System.Data.DataColumnCollection
0x79bda488 14,813 888,780 System.Threading.ReaderWriterLock
0x79bab93c 17,498 909,896 System.Collections.Hashtable
0x02923770 28,877 924,064 System.Xml.DocumentXPathNavigator
0x027882e4 40,203 964,872 System.Data.Common.StringStorage
0x0280cba4 21,157 1,015,536 System.Xml.XPath.XPathAttribute
0x0278489c 29,600 1,184,000 System.Data.DataRelationCollection/DataTableRelationCollection
0x01ba2c28 17,561 2,839,896 System.Collections.Hashtable/bucket[]
0x0252e4b0 14,800 3,433,600 System.Data.DataTable
0x79ba2ee4 145,618 3,494,832 System.Collections.ArrayList
0x0278670c 54,976 3,518,464 System.Data.DataColumnPropertyDescriptor
0x01ba2964 24,879 5,024,760 System.Int32[]
0x0278513c 136,364 5,454,560 System.Data.DataRow
0x0252f5d0 54,760 7,009,280 System.Data.DataColumn
0x01ba26b0 1,262 8,513,840 System.Byte[]
0x000cff48 2,829 14,897,824 Free
0x79b94638 238,884 23,296,388 System.String
0x01ba209c 235,235 40,966,392 System.Object[]
Total 1,509,853 objects, Total size: 136,798,976

Existe un poco más de 1,5 millones de objetos en memoria, que consumen cerca de 136 MB, similar al resultado entregado en la lista anterior.

De esos 1,5 millones de objetos, existe una gran cantidad de strings y arreglos de objeto, como también de filas de datos y columnas de datos. Este comportamiento se presenta cuando se han creado Datasets y no se han liberado.

Un DataSet contiene filas y columnas, y en cada celda encontramos objetos de los tipos básicos como strings, enteros, decimales, objetos, etc. Por lo tanto, estos objetos que se ven al final no viven solos sino que están referenciados desde otro objeto, como podría ser un dataset. No significa que todos estén referenciados, pero con 136 mil filas (DataRow) y 54 mil columnas (DataColumn), varios de esos miles de objetos si lo están.

¿Cuantos DataSets hay?

MT Count TotalSize Class Name
0x0252ce84 1,597 127,760 System.Data.DataSet
Total 1,597 objects, Total size: 127,760

Bueno, tomemos uno al azar y veamos donde nos lleva. Elegimos el objeto en la posición de memoria 0x0834d148.

Name: System.Data.DataSet
MethodTable 0x0252ce84
EEClass 0x0275b43c
Size 80(0x50) bytes
GC Generation: 2
mdToken: 0x0200003b (c:\windows\assembly\gac\system.data\1.0.5000.0__b77a5c561934e089\system.data.dll)
FieldDesc*: 0x0252c4b4
MT Field Offset Type Attr Value Name
0x0252c23c 0x4000583 0x4 CLASS instance 0x00000000 site
0x0252c23c 0x4000584 0x8 CLASS instance 0x00000000 events
0x0252c23c 0x4000582 0 CLASS shared static EventDisposed
>> Domain:Value 0x000c4ac8:NotInit 0x00138380:0x1c331c58 <<
0x0252ce84 0x40003d3 0xc CLASS instance 0x15cee704 defaultViewManager
0x0252ce84 0x40003d4 0x10 CLASS instance 0x0834d198 tableCollection
0x0252ce84 0x40003d5 0x14 CLASS instance 0x0834d220 relationCollection
0x0252ce84 0x40003d6 0x18 CLASS instance 0x00000000 extendedProperties
0x0252ce84 0x40003d7 0x1c CLASS instance 0x1c331c30 dataSetName
0x0252ce84 0x40003d8 0x20 CLASS instance 0x102d0224 _datasetPrefix
0x0252ce84 0x40003d9 0x24 CLASS instance 0x102d0224 namespaceURI
0x0252ce84 0x40003da 0x40 System.Boolean instance 0 caseSensitive
0x0252ce84 0x40003db 0x28 CLASS instance 0x1c2e69c8 culture
0x0252ce84 0x40003dc 0x41 System.Boolean instance 1 enforceConstraints
0x0252ce84 0x40003dd 0x42 System.Boolean instance 0 fInReadXml
0x0252ce84 0x40003de 0x43 System.Boolean instance 0 fInLoadDiffgram
0x0252ce84 0x40003df 0x44 System.Boolean instance 0 fTopLevelTable
0x0252ce84 0x40003e0 0x45 System.Boolean instance 0 fInitInProgress
0x0252ce84 0x40003e1 0x46 System.Boolean instance 1 fEnableCascading
0x0252ce84 0x40003e2 0x47 System.Boolean instance 0 fIsSchemaLoading
0x0252ce84 0x40003e3 0x2c CLASS instance 0x00000000 rowDiffId
0x0252ce84 0x40003e4 0x48 System.Boolean instance 0 fBoundToDocument
0x0252ce84 0x40003e5 0x30 CLASS instance 0x00000000 onPropertyChangingDelegate
0x0252ce84 0x40003e6 0x34 CLASS instance 0x00000000 onMergeFailed
0x0252ce84 0x40003e7 0x38 CLASS instance 0x00000000 onDataRowCreated
0x0252ce84 0x40003e8 0x3c CLASS instance 0x00000000 onClearFunctionCalled
0x0252ce84 0x40003e9 0 CLASS shared static zeroTables
>> Domain:Value 0x000c4ac8:NotInit 0x00138380:0x1c331c20 <<

Mmm, nada más que un dataset. No se si podría haber encontrado otra cosa . Veamos el nombre de éste, en la posición 0x1c331c30 (línea blanca arriba).

String: NewDataSet

. El nombre genérico no da pistas para encontrar alguna parte del código que lo esté creando. Vemos entonces quién lo está apuntando.

Scan Thread 10 (0x1cac)
Scan Thread 16 (0xa00)
Scan Thread 17 (0x1908)
Scan Thread 5 (0xa0c)
Scan Thread 4 (0x1dcc)
Scan Thread 19 (0x1a6c)
Scan Thread 3 (0x1584)
Scan Thread 2 (0x444)
Scan Thread 20 (0x15f4)
ESP:36ff548:Root:0x1c6b59a8(System.Threading.Thread)->0x15cecad4(System.Runtime.Remoting.Messaging.IllogicalCallContext)->0x15cecae0(System.Collections.Hashtable)->0x15cecb14(System.Collections.Hashtable/bucket[])->0x15cec81c(System.Web.HttpContext)->0x15cec608(System.Web.Hosting.ISAPIWorkerRequestInProcForIIS6)->0x182d81c4(System.Web.HttpWorkerRequest/EndOfSendNotification)->0x14339e70(System.Web.HttpRuntime)->0x182d7fac(System.Web.Util.Profiler)->0x14358454(System.Collections.ArrayList)->0x1d89d7b0(System.Object[])->0x834d148(System.Data.DataSet)
Scan Thread 22 (0x1098)
Scan Thread 24 (0xcd8)
.....<recortado por el bien de esta página>...
Scan Thread 67 (0x1938)
Scan Thread 54 (0x618)
Scan HandleTable 0xc9ec0
Scan HandleTable 0xcd008
Scan HandleTable 0x147008

El thread 20, que está procesando un requerimiento en la extensión ISAPI de asp.net en IIS6 (System.Web.Hosting.ISAPIWorkerRequestInProcForIIS6) tiene una referencia fuerte al objeto. Vemos también un HashTable, el Contexto y Runtime de http, los cuales se pueden considerar normales en el ciclo de vida de un requerimiento web.

Sin embargo, hay un invitado especial en esta lista de referencias. Éste es System.Web.Util.Profiler, del cual no hay mucha información disponible, pero después de examinarlo, ya podemos inferir de quién se trata. Veamos su contenido.

Name: System.Web.Util.Profiler
MethodTable 0x021c49d0
EEClass 0x0215912c
Size 28(0x1c) bytes
GC Generation: 2
mdToken: 0x0200029d (c:\windows\assembly\gac\system.web\1.0.5000.0__b03f5f7f11d50a3a\system.web.dll)
FieldDesc*: 0x021c4704
MT Field Offset Type Attr Value Name
0x021c49d0 0x4001076 0x8 System.Int32 instance 1478 _requestNum
0x021c49d0 0x4001077 0xc System.Int32 instance 7500 _requestsToProfile
0x021c49d0 0x4001078 0x4 CLASS instance 0x14358454 _requests
0x021c49d0 0x4001079 0x14 System.Boolean instance 0 _pageOutput
0x021c49d0 0x400107a 0x15 System.Boolean instance 1 _isEnabled
0x021c49d0 0x400107b 0x16 System.Boolean instance 1 _oldEnabled
0x021c49d0 0x400107c 0x17 System.Boolean instance 0 _localOnly
0x021c49d0 0x400107d 0x10 System.Int32 instance 0 _outputMode

Recordando las propiedades de la traza de asp.net, podemos ver asombrosas similitudes con las propiedades. Veamos la definición de la traza en el archivo web.config. La información oficial dice:

El dump dice que la traza estaba habilitada (_isEnabled), no estaba local (_localOnly), que tenía marcado para almacenar hasta 7.500 requerimientos (segunda línea blanca) y que habían 1478 almacenados (primera línea blanca). El resto de las propiedades las pueden chequear ustedes. Recordemos que habían 1597 DataSets en memoria.

El objeto _requests es un System.Collections.ArrayList y los 1478 objetos dentro suman casi la totalidad de memoria manejada, que si bien recordarán, sumaba cerca de 136 MB.

sizeof(0x14358454) = 91,258,512 (0x5707e90) bytes (System.Collections.ArrayList)

Entonces, la condición de memoria elevada, se da en parte porque hay ~90 MB de objetos referenciados por la traza de asp.net. También hay una cantidad de importante de memoria (~70 MB) consumida por dlls y ensamblados (ver la primera imagen.)

Conclusiones

Las conclusiones que se pueden obtener en este caso son:

No todos las pérdidas de memoria son producto de errores en la codificación.
Si vas a habilitar la traza en producción, recuerda deshabilitarla una vez que termines.
También, si no vas a poder leer la información de 7500 trazas, configúralo para que almacene menos.

Saludos,
Patrick

Signos vitales de un servidor: Parte II (procesador)

pmackay — Mon, 17 Dec 2007 04:08:00 GMT

Continuando con los signos vitales de un servidor, hoy día veremos en la segunda parte, el procesador.

El análisis del procesador es bastante más simple que el de la memoria. Hay dos contadores importantes. Uno de ellos corresponde al uso del procesador, con dos matices especiales; uso del procesador en modo usuario y el otro en modo kernel. El otro contador corresponde a la cantidad de requerimientos encolados del procesador.

Como ya hemos visto en otros posts, Windows utiliza dos modos de ejecución. Uno de ellos es el modo usuario, donde corren las aplicaciones que nosotros ejecutamos y el otro es el modo Kernel, en el cual corre el kernel del sistema operativo.

¿Por qué es importante esta explicación?

Si logramos identificar quién está consumiendo el procesador, podremos inferir y tener mejores pistas para encontrar al culpable del consumo de éste.

Si te preguntas ¿para qué necesitas saber el modo (usuario o kernel) que está consumiendo el procesador, si mirando el task manager sabrás fácilmente qué aplicación es responsable?

Bueno. Hay un par de razones. Veamos cada una de ellas.

1.- Task manager te dirá la aplicación que está consumiendo el procesador, pero no te dirá más. Solo la aplicación. Perfmon por otra parte te podrá entregar más información. Process Explorer de Sysinternals es una excelente herramienta.
2.- Task manager no muestra siempre el consumo del kernel.

El segundo punto no está tan relacionado con aplicaciones, pero vale la pena aclarar que hay ciertas actividades del kernel que no son cuantificadas por Task Manager, o son cuantificadas pero no desplegadas. Recordemos que el kernel corresponde al proceso llamado System, siempre con el PID 4. Entonces puede parecer que tu sistema tiene bajo uso del procesador, pero el kernel está trabajando activamente. Para mejores resultados en el despliegue de los recursos consumidos, puedes utilizar Process Explorer.

Resumiendo

Podemos decir que para una aplicación específica:

El porcentaje de consumo en modo kernel corresponde a las actividades que debe realizar el kernel para cumplir con los requerimientos de la aplicación, como por ejemplo, trabajar con archivos, mover memoria, escribir en sockets, pintar ventanas, etc.

El porcentaje de consumo en modo usuario corresponde a la ejecución de código sin interacción con el kernel, es decir, algo así como "el código sin acceso a recursos externos." Si estuviésemos utilizando un profiler, diríamos entonces que corresponde a lo que se llama "exclusive time."

Contadores

La siguiente es la lista de contadores de perfmon a utilizar, que como podrán notar, es muy breve, repetitiva y casi no requiere mayor explicación.

Objeto System, contador Processor Queue Length: muestra la cantidad de requerimientos encolados para el procesador.
Objeto Processor, contador % Privileged Time: muestra el porcentaje de tiempo utilizado por el kernel, para todo el procesador
Objeto Processor, contador % User Time: similar al anterior, pero para modo usuario
Objeto Process, contador % Privileged Time, instancia específica. muestra el porcentaje de tiempo utilizado por el kernel, para la aplicación seleccionada en el campo instancia
Objeto Process, contador % User Time, instancia específica: similar al anterior, pero para modo usuario
Objeto Thread, contador % Privileged Time, instancia específica: muestra el porcentaje de tiempo utilizado por el kernel, para un thread especifico de la aplicación seleccionada
Objeto Thread, contador % User Time, instancia especifica: similar al anterior, pero para modo usuario

Probablemente te podrás estar preguntando la utilidad de la información de los últimos 2 contadores. ¿de que te serviría saber cuál es el thread responsable si no se puede hacer mucho con esa información?

Si se puede hacer bastante. Puedes determinar si es un único thread que está ocupando mucho el procesador o es un conjunto de ellos en que todos aportan. Te sirve para obtener pistas.

Podría ser el thread o los threads del GC, el thread del Finalizador, un thread que se quedó pegado en un ciclo, etc. Process Explorer entrega mucha información referente a tipos de procesos e informacón de los threads.

Ok, ya tengo todos los datos...

¿Contra qué comparar la información?

Salvo para el primer contador, no hay punto de comparación. Si el uso del procesador llega a 80% o más, probablemente sea hora de proveer alivio al servidor, ya sea corrigiendo el código o haciendo un upgrade del hardware.

El primer contador no debe ser mayor a 2 multiplicado por la cantidad de procesadores (cores) de tu servidor. Para el caso de HT (Hyper Threading), no estoy seguro, pero creo que no se deben contabilizar.

Ya vendrá una tercera entrega relacionada con el disco duro.

Saludos,
Patrick

Signos vitales de un servidor: Parte I (memoria)

pmackay — Sat, 08 Dec 2007 21:34:00 GMT

¿Qué sucede si uno no se siente bien?; en condiciones normales, uno visita al doctor para saber qué sucede y éste hace una revisión general. Si el doctor encuentra algo interesante, te pide hacer unos exámenes para saber con mayor detalle qué está sucediendo.

Llevando este mismo ejemplo al área de la informática, si tienes un servidor y presientes (o tienes total certeza) que algo no funciona como debiera, un buen punto de partida es determinar si los signos vitales de éste están bien.

El objetivo de este post es dar una pauta general para determinar cuando un servidor Windows 2003, cualquier versión, puede tener algún problema que afecte sus signos vitales. Hoy veremos los signos vitales de la memoria. Los siguientes posts abordarán otras áreas.

Un poco de contexto

Si has escuchado muchas veces la palabra contadores, y no tienes claro a que se refieren cuando lo escuchas, esta sección debiera aclararte un poco. Si tienes claro a que se refiere, puedes saltarte esta sección.

Los contadores son entidades u objetos que mantienen información del funcionamiento de algún programa o sistema operativo (SO de ahora en adelante). Cada programa que utilizas --todos debieran, pero no siempre lo hacen-- genera información con estadística y en tiempo real del funcionamiento de éste, la cual se le informa al SO. A su vez, el SO también genera información que almacena para que nosotros podamos consultarla y saber cómo está funcionando.

Los contadores se categorizan por objetos (por ejemplo, memoria, sistema, sql server, iis) y se pueden o no aplicar a instancias (procesos, sitios web, bases de datos, etc.)

Por ejemplo, un contador de importante SO es la cantidad de memoria disponible que le queda. Este se categoriza en el objeto Memory, y el contador se llama Available MBytes, que nos dice la cantidad de megabytes de memoria disponible. Los nombres de los contadores dependen del idioma del programa o SO. Si estás ejecutando un SO en español, el objeto podría llamarse Memoria y el contador, cantidad de MB disponibles.

La siguiente es una imagen de cómo se agrega este contador utilizando performance monitor (perfmon).

Luego, después de habar agregado los contadores, podrás ver una pantalla como ésta, donde la primera es la representación gráfica y la otra la textual, para la misma información.

Suponiendo que ya se entiende la idea, vamos entonces a ver la primera parte de cómo chequear la salud de un sistema operativo.

Grupos de contadores

Aunque los contadores ya están agrupados de acuerdo a los objetos a los cuales pertenecen, los volveremos a agrupar en clasificaciones más grandes, más generales. Tendremos entonces un grupo para colocar los contadores de memoria, uno para los del procesador, otro para el disco duro, otro para la tarjeta de red y otro para el sistema operativo. En otra oportunidad veremos los asociados a productos específicos como SQL, IIS o .NET.

Contadores de memoria

Los contadores de memoria son variados. Podemos encontrar desde la memoria utilizada por una aplicación, la memoria libre del servidor y la memoria utilizada por los componentes del Kernel del SO. Todas estas son importantes y están de alguna forma relacionadas.

Veamos cada uno de los contadores mencionados y contra qué compararlos (cuando aplica).

Memoria del sistema (incluido kernel)

La memoria libre del sistema la entrega el contador Available MBytes, del objeto Memory. El mismo contador existe retornando el valor en otras unidades como KBytes y Bytes. De acuerdo a la cantidad de memoria que hoy en día tiene un servidor, medir en bytes o kilobytes puede no ser necesario.

Diversa documentación podrán encontrar referente a este contador. Algunos dirán que con 10 MB disponibles, es momento de preocuparse. Otros dirán que 25 MB es una señal de preocupación. En general, menos del 10% de la memoria total instalada ya es reflejo de que al sistema le falta memoria. Por ejemplo, si mi servidor tiene 2GB instalados y le quedan 150 MB disponibles, significa que estoy consumiendo el 92,5% de la memoria. Sin embargo, otros contadores te ayudarán a determinar si esto es cierto o no (si hay o no un problema). Puede ser que tengas mucha memoria ocupada, pero el sistema funcione bien.

Otro contador importante es Pages/sec del objeto Memory. Este refleja la tasa de lecturas y escrituras a disco para resolver problemas de páginas no encontradas (hard faults) en la memoria física, y por ende, tiene que ir al archivo de paginación a buscarla (y guardar otra para hacer espacio).

La información disponible públicamente es muy variada. Desde sitios que dicen que valores de más de 100 son preocupantes. Otros dicen que más de 5 de forma constante es preocupante. Lamentablemente ninguna de esas medidas es agnóstica y depende de otros factores (como el disco). Una medida agnóstica se obtiene al multiplicar este contador por Avg. Disk sec/Transfer del objeto Physical Disk, en la instancia (disco) donde está el archivo de paginación. El resultado de multiplicar ambos corresponde al porcentaje de tiempo de acceso a disco. Si es mayor a 10%, está paginando mucho, lo que puede ser producto de falta de memoria.

Los contadores de memoria del kernel se deben comparar contra valores en unas tablas específicas. Estos son Pool Paged Bytes y Pool Nonpaged Bytes del objeto Memory. Las tablas se encuentran a continuación, tanto para Windows 2000 como Windows 2003 (clic para agrandar).

Windows 2003

Windows 2000 SP4

Los valores obtenidos para cada unos de los contadores, tanto para paged como nonpaged, corresponden a la cantidad de bytes de cada pool que ha sido utilizado. Si es menor al 50% del pool, todo está bien. Mayor a 50% y menor a 80%, es hora de preocuparse. Si es mayor a 80%, hay problemas.

¿Cómo se mide?

Si obtuviste un valor de 56 MB en el contador de paged pool bytes y tu sistema es Windows 2003 con 4 GB y estás usando /3GB, el tamaño total del paged pool bytes es de 258 MB (revisa la tabla). La tasa de uso (56/258) es cercana al 21%, lo que nos dice que nuestro sistema está bien. Lo mismo para nonpaged pool bytes, pero considerando el otro valor en la tabla.

El último contador relacionado con la memoria en el kernel corresponde a Free System Page Table Entries (PTEs), del objeto Memory. Los PTEs son estructuras internas utilizadas por el componente del kernel llamado Memory Manager y que tiene como objetivo administrar la memoria.

Si este contador se reduce mucho (menos de 15 mil o 10 mil), habrá problemas. Usualmente este contador se ve afectado por la utilización de la opción /3GB sin utilizar la opción /userva. Esta anécdota ocurrió en un caso donde no se utilizó /userva.

Después de haber visto las opciones para el sistema y kernel, podemos ver las opciones de memoria disponibles para las aplicaciones.

Memoria de aplicaciones

Para medir la memoria de una aplicación específica, tengo que agregar los siguientes contadores, y asociarlos con el proceso que quiero medir (instancia en la parte derecha de la ventana):

Objeto Process, contador Private Bytes
Objeto Process, contador Virtual Bytes
Objeto Process, contador Working Set

El primer contador corresponde a la memoria privada el proceso. El segundo contador, a la memoria virtual del proceso. Para un mejor entendimiento de los tipos de memoria que miden, te recomiendo la lectura de estos posts:

El working set corresponde a la cantidad de memoria privada (sumada a la memoria usada por dlls y otras estructuras) que está cargada en memoria real (física). A grosso modo, la suma de los working set de todos los procesos no podrá superar la memora física de tu máquina.

Lamentablemente no hay valores contra qué compararlos, pero de acuerdo a lo que vimos en el segundo post de la lista de más arriba, la memoria virtual no podrá superar los 2 GB en un sistema de 32 bits.

Si virtual bytes es muy elevado en comparación con private bytes, podría haber un problema de fragmentación de memoria. ¿Qué significa muy elevado?; tampoco hay una respuesta, pero unas 10 veces debiera ser preocupante, como también es preocupante acercarse a los 2 GB. Claro que las 10 veces dependerá de la memoria que use nuestro proceso. Si un proceso utiliza 10 MB de memoria privada, es normal que utilice 100 MB de memoria virtual.

Hay muchas cosas relativas, pero lo importante es monitorearlos en el tiempo.

Si virtual bytes sube y sube sin descender (o descendiendo menos de lo que aumenta), habrá un problema de fragmentación de memoria, aunque dependerá de cómo aumente private bytes también.

Si private bytes sube y sube sin descender (o descendiendo menos de lo que aumenta), tendrás un problema de pérdida de memoria o memory leak. Private bytes no podrá ser superior al máximo de memoria virtual de un proceso (2GB).

Otros contadores

Sin duda, hay muchos más contadores, pero para determinar signos vitales, con éstos basta.

Desde Santiago de Chile,
Patrick

Desmitificando la Encriptación (ex MTJ.NET)

pmackay — Thu, 29 Nov 2007 22:00:00 GMT

Aclaración

El siguiente contenido apareció publicado en la revista MTJ.NET en MSDN en español en el año 2005, en partes I y II. Debido a que la revista MTJ.NET no está al aire hoy, he optado por lanzarlo al aire nuevamente desde mi blog en un sólo documento.

A los suscriptores RSS les pido disculpas de antemano por haber publicado diferentes versiones.

Código fuente disponible aquí.

Introducción

Cuando es necesario darle seguridad a ciertos datos de nuestra aplicación, y buscamos información en el Web que nos permita lograrlo, es normal que hablemos (o leamos) de encriptación, y que irremediablemente salgan a la luz palabras tales como algoritmos simétricos, asimétricos y Hash. Estos términos pueden generar temor o dar la sensación de ser complejos. La motivación de este documento es mostrar qué es la encriptación sin necesidad de profundizar en cómo funciona un algoritmo internamente; y también indicar las malas prácticas que se realizan popularmente. Se revisará además la forma correcta de utilizar los algoritmos de encriptación, dónde se deben usar y dónde no.

Debido a lo extenso del tema en cuestión y a que es preferible realizar todas las explicaciones correspondientes, fue necesario dividir el documento en dos partes. Lo que contendrá cada parte está detallado en el siguiente índice.

Agradecimientos

Antes de comenzar deseo agradecer tanto el apoyo de Mike Giagnocavo como el de la información disponible en su blog (http://www.atrevido.net/). Sin sus consejos y correcciones, los ejemplos de este documento y la demostración no habrían quedado de excelente calidad y listos para utilizar.

Introducción, alcance y preguntas iniciales

La seguridad de los datos de cualquier sistema es algo muy importante, y no siempre recibe la atención y dedicación necesarias. Podemos formular las siguientes preguntas básicas y es probable que encontremos falencias de seguridad que pueden comprometer a nuestro sistema:

¿Se está almacenando la información crítica de forma segura?
¿Qué entendemos por seguro?
Si se está encriptando, ¿Qué algoritmo se está utilizando?
¿Se permite la desencriptación de datos que no debieran poder desencriptarse?
¿Cómo está realizándose la encriptación?

Adicionalmente, podemos complementar con preguntas más complejas:

¿Dónde están almacenadas la o las llaves?
¿Con qué frecuencia se cambian las llaves?
¿Cómo se enfrenta el problema de cambiar las llaves con tanta frecuencia?
¿Con qué criterio se definen las nuevas llaves?

Es probable que algunas de las preguntas básicas no sean respondidas adecuadamente. Si esto es así, sería recomendable hacer una revisión de los criterios y metodologías que se están utilizando, y determinar si es necesario hacer modificaciones o rehacer esas funcionalidades. Si el pensamiento es que esto no genera utilidad, cabe hacerse las siguientes preguntas: ¿Qué le sucedería al negocio si alguien accediese a cualquiera de los datos privados del sistema? ¿Se verá comprometida la seguridad con hechos como éste? De seguro, en ese momento el pensamiento sería que valdría la pena. Entonces, manos a la obra.

El alcance de este documento es dar a conocer los distintos métodos que existen para proteger tanto el almacenamiento como el envío de la información. Este documento NO tiene como intención ser un manual de seguridad. Esto es lo mínimo que debe tener una organización para no estar al descubierto en sus procesos. Se debe entender que existen libros dedicados a la seguridad. Aquí se está danto el puntapié inicial para salir del desconocimiento que existe sobre este tema. Es responsabilidad tanto de los administradores de sistemas operativos como del arquitecto de soluciones definir las reglas, dónde almacenar sus llaves, los criterios de cambio de llaves y también los lugares donde almacenará la información.

Habiendo introducido el tema y definido el alcance, comencemos con la revisión de los algoritmos y los distintos tipos que existen.

Definición de algoritmos

Como se mencionó con anterioridad, existen distintos tipos de algoritmos de encriptación, pero algo que no se ha mencionado hasta ahora son los “algoritmos” que se cree que encriptan, pero que no hacen nada más que transformar texto (o información). El objetivo de hacer esta distinción es mostrar algunas malas prácticas que se cometen, pensando que cualquier algoritmo que cambia de cierta forma un texto, está realizando encriptación de datos. Estos algoritmos podremos llamarlos simplemente "Transformaciones".

Como se está hablando de encriptación, se revisarán también los algoritmos que han sido construidos con distintos fines y que están agrupados en distintas categorías. ¿Cuál es la funcionalidad de los algoritmos dentro de cada uno de estos grupos? Cada uno tiene un objetivo y un problema que atacar, y por lo mismo hay casos en los que debe utilizarse uno y sólo uno de estos algoritmos, como también casos en los que debe utilizarse algoritmos de más de un grupo.

Antes de revisar los escenarios, se debe aclarar el concepto de llave. La llave de encriptación es una serie de carácteres, de determinado largo, que se utiliza para encriptar y desencriptar la información que se quiere proteger. El largo de la llave depende del algoritmo. Existen llaves privadas y públicas, que serán detalladas más adelante. Veamos los siguientes escenarios.

Escenario 1: Necesito almacenar información crítica que deberá poder descifrarse, y seré yo el único que haga todo el proceso. Nadie más tendrá acceso a la llave con que se encriptará y desencriptará la información.
Escenario 2: Necesito que me envíen información crítica que yo desencriptaré posteriormente, pero necesito que las personas que me van a enviar información pueden encriptarla libremente, pero no desencriptarla. En este caso, se deja disponible una llave pública para que ellos encripten y yo tendré mi llave privada de encriptación en forma segura.
Escenario 3: Necesito almacenar o enviar información crítica de forma segura, pero que no requerirá ser desencriptada para su validación, o que es extremadamente importante verificar que no haya sido modificada en el camino.

Estos son los tres escenarios más comunes. Es probable que te preguntes para qué puede haber casos como el 3. Lo veremos más adelante con ejemplos, destacando ventajas y desventajas. Los tres escenarios calzan con los algoritmos listados a continuación:

Escenario 1: Encriptación simétrica
Escenario 2: Encriptación asimétrica
Escenario 3: Hash de información

Antes de comenzar a revisar cada uno de estos algoritmos, revisemos una muy mala práctica que se utiliza más de lo que debiera, que corresponde a la utilización de “algoritmos” o mejor dicho, transformaciones del contenido.

Malas prácticas o transformaciones

Antes mencionamos que es común escuchar o ver que se utilizan ciertas transformaciones como métodos de protección. Como la comparación se hace con el ojo humano, si se tiene una cadena de texto y se decide transformar aplicándole un XOR o desplazando los bytes, el resultado de esa transformación nos produce el efecto de que está encriptado, por que no lo podemos entender (nuestro cerebro no lo entiende). Debido a esto, no vamos a hacer el ejemplo transformando texto sino que lo haremos transformando una imagen. Se aplicarán los dos efectos mencionados recién, XOR y Desplazamiento, y se verá que es efectivamente lo que hacen. El motivo de utilizar una imagen es para que nuestro ojo no se engañe con las apariencias.

Nuestro ejemplo nos presenta una pantalla como la que se muestra en la Figura 1, donde tenemos dos botones; uno para cargar la imagen, otro para aplicarle las transformaciones XOR, y otro para desplazar los bytes:

Figura 1.

Si se presiona Transformar, el resultado será el que se muestra en la figura 2:

Figura 2: Resultado de las transformaciones.

Como se puede apreciar, no se produce una encriptación sino sólo una transformación de los datos (más adelante verás cómo queda la imagen realmente encriptada). Este tipo de transformaciones no protege nuestra información. Hagamos ahora las siguientes preguntas: ¿Cuánta seguridad existe con estas transformaciones? ¿Cuánto demorará un hacker en retransformar esto? El hacker obtiene la respuesta en menos de lo que te toma a ti leer sólo esta línea. Hacerle modificaciones a este “algoritmo” no sirve. La encriptación no es trivial de hacer, pero es mucho más fácil de usar. Más adelante conocerás la cantidad de años que estuvo estudiándose el algoritmo Rijndael o AES, para ser declarado vencedor.

El código que utilizamos para realizar la transformación XOR es el siguiente. El código de desplazamiento es muy similar. Este, al igual que todo el código del documento, está disponible en el archivo adjunto con este artículo. Por motivos que no corresponde explicar aquí, ya que no entran en el objetivo del documento, con la imagen que se está trabajando es necesario comenzar desde la posición 34, ya que si se comienza desde el byte 0 transformando, el archivo BMP ya no es posible visualizarlo.

Lo único que hace este “algoritmo” es aplicar XOR a un arreglo de bytes. Para aplicarlo sobre texto lo único que hay que hacer son las transformaciones de bytes a texto y viceversa. Como explicación sencilla de este proceso, podemos decir que lo que hace es tomar cada uno de los bytes y aplicarle un XOR (representado por el símbolo "^" en el código). Un XOR corresponde al resultado de la comparación bit a bit de dos bytes. En este caso, un byte viene del texto a transformar y el otro del número 87 elegido al azar.

public class TransformacionXOR
{
       private static int _XOR = 87;

       public static byte[] Codificar(byte[] bytACodificar)
       {
              for (int _intPos = 34; _intPos < bytACodificar.Length; _intPos++)
                     bytACodificar[_intPos] = (byte) (_XOR ^ bytACodificar[_intPos]);
              return bytACodificar;
       }

       public static byte[] DeCodificar(byte[] bytADecodificar)
       {
              for (int _intPos = 34; _intPos < bytADecodificar.Length; _intPos++)
                     bytADecodificar[_intPos] = (byte) (_XOR ^ bytADecodificar[_intPos]);
              return bytADecodificar;
       }
}

Como ven, este algoritmo tan lineal no nos da ninguna seguridad; y por lo mismo, jamás debe utilizarse para proteger información. No debe creerse que es XOR el responsable de esto. XOR es muy útil en otros contextos, pero no se puede utilizar de esta forma.

Nota: Antes de continuar, es muy importante aclarar lo siguiente. Si se va a proteger información, el proceso DEBE realizarse a conciencia y con algoritmos probados. Además, se debe utilizar el algoritmo de la forma en que fue concebido. Implementaciones a medias, son tan inútiles como las transformaciones recién vistas o como la no utilización de ésta. O el proceso se hace bien, o no se hace.

Veamos ahora los algoritmos reales de encriptación.

Encriptación simétrica

Cuando hablamos de encriptación y no de transformación, ya estamos adentrándonos en temas de mayor protección, de algoritmos conocidos y seguridad real. El proceso de realizar una encriptación es complejo para ser entendido por nosotros mismos, pero no es limitante para conocer cuáles son los pasos para utilizarlos y qué errores no se deben cometer.

Dentro de los algoritmos de encriptación simétrica podemos encontrar los siguientes, algunos más seguros que otros.

DES (Digital Encryption Standard)
Creado en 1975 con ayuda de la NSA (National Security Agency); en 1982 se convirtió en un estándar. Utiliza una llave de 56 bit. En 1999 logró ser quebrado (violado) en menos de 24 horas por un servidor dedicado a eso. Esto lo calificó como un algoritmo inseguro y con falencias reconocidas.

3DES (Three DES o Triple DES)
Antes de ser quebrado el DES, ya se trabajaba en un nuevo algoritmo basado en el anterior. Este funciona aplicando tres veces el proceso con tres llaves diferentes de 56 bits. La importancia de esto es que si alguien puede descifrar una llave, es casi imposible poder descifrar las tres y utilizarlas en el orden adecuado. Hoy en día es uno de los algoritmos simétricos más seguros.

IDEA (International Data Encryption Algorithm)
Más conocido como un componente de PGP (encriptación de mails), trabaja con llaves de 128 bits. Realiza procesos de shift y copiado y pegado de los 128 bits, dejando un total de 52 sub llaves de 16 bits cada una. Es un algoritmo más rápido que el DES, pero al ser nuevo, aún no es aceptado como un estándar, aunque no se le han encontrado debilidades aún.

AES (Advanced Encryption Standard)
Este fue el ganador del primer concurso de algoritmos de encriptación realizado por la NIST (National Institute of Standards and Technology) en 1997. Después de 3 años de estudio y habiendo descartado a 14 candidatos, este algoritmo, también conocido como Rijndael por Vincent Rijmen y Joan Daemen, fue elegido como ganador. Aún no es un estándar, pero es de amplia aceptación a nivel mundial.

En nuestra demo utilizaremos el algoritmo AES. .NET provee implementaciones de AES, DES y TripleDES entre otros.

El algoritmo más seguro hoy el AES, aunque 3DES también es muy seguro. Este último se utiliza cuando hay necesidad de compatibilidad. AES 128 es aproximadamente 15% más rápido que DES, y AES 256 sigue siendo más rápido que DES.

Cualquiera de estos algoritmos utiliza los siguientes dos elementos; ninguno de los dos debe pasarse por alto ni subestimar su importancia:

IV (Vector de inicialización)
Esta cadena se utiliza para empezar cada proceso de encriptación. Un error común es utilizar la misma cadena de inicialización en todas las encriptaciones. En ese caso, el resultado de las encriptaciones es similar, pudiendo ahorrarle mucho trabajo a un hacker en el desciframiento de los datos. Tiene 16 bytes de largo. Puedes encontrar más información acerca de IV en http://www.atrevido.net/blog/PermaLink.aspx?guid=6136ce81-9fa1-4995-bb3e-15bc5f1f5899.

Key (llave)
Esta es la principal información para encriptar y desencriptar en los algoritmos simétricos. Toda la seguridad del sistema depende de dónde esté esta llave, cómo esté compuesta y quién tiene acceso. El largo de las llaves depende del algoritmo. Al final del documento se darán algunas recomendaciones para el almacenamiento, generación y rotación de llaves.

Algoritmo	Largos válidos (bits)	Largo por defecto (bits)
DES	64	64 (8 bytes)
TripleDES	128, 192	192 (24 bytes)
Rijndael	128, 192, 256	256 (32 bytes)

Veamos ahora nuestra aplicación y cómo funciona para encriptación y desencriptación con algoritmos simétricos, específicamente Rijndael (Ver figura 3):

Figura 3: Resultado de la encriptación con Rijndael aplicado sobre una imagen y texto.

Lo primero que debemos hacer es especificar una llave de encriptación. Una cadena de texto se utiliza en el ejemplo. En la caja de más abajo se puede ingresar el texto que se desea encriptar. Luego de presionar "Encriptar" se obtiene el resultado de la encriptación en la caja del medio, y como es de esperarse, presionando "DesEncriptar" se obtiene el texto desencriptado en la última caja de texto.

Si revisamos el código fuente que realiza la encriptación y desencriptación, encontraremos algo de mayor complejidad con respecto las transformaciones anteriormente vistas.

public class MiRijndael
{
       public static byte[] Encriptar(string strEncriptar, byte[] bytPK)
       {
              Rijndael miRijndael = Rijndael.Create();
              byte[] encrypted = null;
              byte[] returnValue = null;

              try
              {
                     miRijndael.Key = bytPK;
                     miRijndael.GenerateIV();

                     byte[] toEncrypt = System.Text.Encoding.UTF8.GetBytes(strEncriptar);
                     encrypted = (miRijndael.CreateEncryptor()).TransformFinalBlock(toEncrypt, 0, toEncrypt.Length);

                     returnValue = new byte[miRijndael.IV.Length + encrypted.Length];
                     miRijndael.IV.CopyTo(returnValue, 0);
                     encrypted.CopyTo(returnValue, miRijndael.IV.Length);
              }
              catch { }
              finally { miRijndael.Clear(); }

              return returnValue;
       }

       public static string Desencriptar(byte[] bytDesEncriptar, byte[] bytPK)
       {
              Rijndael miRijndael = Rijndael.Create();
              byte[] tempArray = new byte[miRijndael.IV.Length];
              byte[] encrypted = new byte[bytDesEncriptar.Length - miRijndael.IV.Length];
              string returnValue = string.Empty;

              try
              {
                     miRijndael.Key = bytPK;

                     Array.Copy(bytDesEncriptar, tempArray, tempArray.Length);
                     Array.Copy(bytDesEncriptar, tempArray.Length, encrypted, 0, encrypted.Length);
                     miRijndael.IV = tempArray;

returnValue = System.Text.Encoding.UTF8.GetString((miRijndael.CreateDecryptor()).TransformFinalBlock(encrypted, 0, encrypted.Length));

              }
              catch { }
              finally { miRijndael.Clear(); }

              return returnValue;
       }

       public static byte[] Encriptar(string strEncriptar, string strPK)
       {
              return Encriptar(strEncriptar, (new PasswordDeriveBytes(strPK, null)).GetBytes(32));
       }

       public static string Desencriptar(byte[] bytDesEncriptar, string strPK)
       {
              return Desencriptar(bytDesEncriptar, (new PasswordDeriveBytes(strPK, null)).GetBytes(32));
       }
}

Explicar el funcionamiento del algoritmo no entra dentro del alcance de este documento y, siendo sincero, desconozco cómo funciona. Tampoco creo que sea necesario que nosotros sepamos cómo funcionan los algoritmos de encriptación. Lo importante es utilizarlos bien.

Nota: Para obtener la llave del algoritmo, dado que una cadena de carácteres generada por un humano en un formulario es considerada poco variada debido a que los carácteres utilizados son pocos (a->z, A->Z, 0->9), se le aplica un proceso de variación con la clase PasswordDeriveBytes y se le pide un resultado de 32 bytes. Esto nos retorna una llave con carácteres variados, ideal para la encriptación. PasswordDeriveBytes utiliza Hash para generar la salida. Hash se verá más adelante.

Volviendo al ejemplo, si se presiona "Encriptar" nuevamente, las veces que se desee, se verá que el resultado de la encriptación varía. ¿Por qué sucede esto, si el resultado de la encriptación debiera ser el mismo? La variación en el resultado de una encriptación se produce por dos variantes en el proceso, el Key (o llave de encriptación) y el IV (o vector de inicialización). En este caso se está utilizando el mismo Key (explícito en la caja de texto) pero el IV está variando todas las veces. ¿Porqué varía el IV? ¿Qué es el IV?

El IV o vector de inicialización es un concepto no entendido del todo, por que algunos creen que se puede encriptar “sin él”. El IV cumple un rol pequeño, pero muy importante. El único motivo por el cual existe es para apoyar el proceso de encriptación, permitiendo exactamente que ocurra lo que se observó en la caja de texto, es decir, la variación del resultado del proceso de encriptación. El IV no debe considerarse como una segunda llave, por que no lo es. Es una ayuda y por lo mismo, no es un dato que haya que esconder, si no que basta con almacenarlo para que cuando se vaya a desencriptar se utilice el mismo IV que se utilizó en la encriptación. En el ejemplo, el IV se retorna como parte del resultado de la encriptación y se genera cada vez que se realiza un encriptación. Su largo es de 16 bytes para el algoritmo de Rijndael.

Nota: Utilizar siempre un mismo IV para no tener que almacenarlo es equivalente en seguridad a no utilizar encriptación. La seguridad mal implementada es más insegura que no implementarla. ¿Por que? Porque da la creencia de tener seguridad, y produce una confianza que es nociva. Si no tienes seguridad en tu aplicación, eso lo sabes y estás preocupado, pero si se tiene una seguridad mal implementada se cree que se tiene, pero no es así.

Con la implementación entregada en la demo, el IV está correctamente utilizado. En las imágenes de la segunda parte se aplica el mismo algoritmo de encriptación, pero utilizando variaciones en el modo de ciframiento. En la segunda imagen se aplica el modo ECB y en la tercera CBC. Estos modos especifican al algoritmo cómo debe funcionar. El modo más seguro, que también es el modo por defecto es CBC.

El modo de ciframiento ECB no utiliza IV, por lo mismo no debe usarse como modo de ciframiento, a menos que sea necesario por compatibilidad. Esta es otra muestra de porqué es útil el IV y porqué debe usarse, y que sucede con la encriptación cuando el IV no varía nunca.

Es importante considerar que en los algoritmos simétricos se utiliza la misma llave para encriptar y desencriptar. En los algoritmos asimétricos se verá que existen dos llaves, una pública para encriptar y una privada para desencriptar.

Encriptación Asimétrica

La encriptación asimétrica permite que dos personas puedan enviarse información encriptada, sin necesidad de compartir la llave de encriptación. Se utiliza una llave pública para encriptar el texto y una llave privada para desencriptar. A pesar de que puede sonar extraño que se encripte con la llave pública y desencripte con la privada, el motivo para hacerlo es el siguiente: si alguien necesita que le envíen la información encriptada, deja disponible la llave pública para que quienes le desean enviar algo lo encripten. Nadie puede desencriptar algo con la misma llave pública. El único que puede desencriptar es quien posea la llave privada, quien justamente es el que recibe la información encriptada.

Los algoritmos de encriptación asimétrica más conocidos son:

RSA (Rivest, Shamir, Adleman)
Creado en 1978, hoy es el algoritmo de mayor uso en encriptación asimétrica. Tiene dificultades para encriptar grandes volúmenes de información, por lo que es usado por lo general en conjunto con algoritmos simétricos.
Diffie-Hellman (& Merkle)
No es precisamente un algoritmo de encriptación sino un algoritmo para generar llaves públicas y privadas en ambientes inseguros.
ECC (Elliptical Curve Cryptography)
Es un algoritmo que se utiliza poco, pero tiene importancia cuando es necesario encriptar grandes volúmenes de información.

El tamaño de la llave es el siguiente:

Algoritmo	Largos válidos (bits)	Largo por defecto (bits)
RSA	384 a 16.384 (incrementos de a 8)	1.024

Mientras más larga sea la llave, más seguro será. La relación con los algoritmos simétricos no es directa. En este caso, una llave de 1024 bits de RSA es equivalente en seguridad a una de 75 bits de un algoritmo simétrico.

Como era de esperar, en nuestra demostración utilizaremos el algoritmo de mayor uso, RSA. Debido a que el funcionamiento es diferente comparado con el algoritmo anterior, la pantalla varía levemente. Existirá una zona donde se desplegará la llave pública generada, dejándole el almacenamiento de la llave privada a la clase miRSA.

La idea de esto es que exista una clase que provea una llave pública, para que el cliente encripte la información y luego éste le envíe lo encriptado a la misma clase, para que con la llave privada la desencripte. En este caso, se ha dejado el método desencriptar como público, por que se necesita para pintar el resultado en el formulario. Este no debiera ser un método público en una implementación real.

Antes de ver la demo, es necesario revisar el siguiente capítulo, debido a que la encriptación con RSA no es eficiente y tiene limitaciones de tamaño.

Encriptación Asimétrica + Simétrica

Debido a que la encriptación asimétrica es casi 1000 veces más lenta que la simétrica, cuando la información a encriptar es mucha, se utiliza una combinación de algoritmos. El algoritmo simétrico se utiliza para encriptar la información y el asimétrico para encriptar la llave del algoritmo simétrico con que se encriptó la información. Entonces, el proceso es mucho más rápido. Esta técnica se utiliza hoy en SSL en la negociación entre el navegador del cliente y el servidor. En cada ida y vuelta al servidor se generan nuevas llaves y se realiza todo el proceso. También es utilizada por Windows en la encriptación de los archivos.

Otro motivo para utilizar esta encriptación combinada es la necesidad de encriptar textos largos. La encriptación asimétrica además de ser ineficiente en tiempo, tiene limitaciones de tamaño. El tamaño máximo depende del largo de la llave. En la demostración, puedes probar colocando mucho texto y verás que se cae.

Estas limitantes nos obligan a utilizar el método combinado.

Nuestra demostración implementa ambos métodos, y se decide cuál utilizar con la selección del check Utilizar Simétrico. La aplicación se ve como se muestra en la figura 4 y figura 5. Antes de hacer cada demo, se debe seleccionar si se utilizará en conjunto con encriptación simétrica.

Figura 4: Encriptación utilizando solamente RSA.

Figura 5: Encriptación utilizando RSA con Rijndael.

El resultado de la encriptación es notoriamente más largo.

Como vemos, si generamos una llave y luego procedemos con los siguientes pasos, la encriptación se produce en un lado y la desencriptación en otro. Incluso .NET provee el método ToXmlString() de RSACryptoServiceProvider que retorna la llave en formato XML, ideal para ser enviada por algún medio público (Web Service, Archivo XML, etc.).

Dependiendo de si se utiliza en conjunto con algún algoritmo simétrico, la encriptación y desencriptación es diferente. Como algoritmo simétrico se utiliza AES ó Rijndael.

El código de nuestra clase miRSA es el siguiente:

public class miRSA
{
       private RSACryptoServiceProvider _objRSA = null;

       public miRSA()
       {
              this._objRSA = new RSACryptoServiceProvider(1024);
       }

       public string ObtenerLlavePublica()
       {
              return this._objRSA.ToXmlString(false);
       }

       public string DesEncriptar(byte[] bytEncriptado, bool blnConSimetrico)
       {
              if (blnConSimetrico)
              {
                     byte[] keyArray = new byte[_objRSA.KeySize/8];
                     byte[] encrypted = new byte[bytEncriptado.Length - keyArray.Length];
                     Array.Copy(bytEncriptado, 0, keyArray, 0, keyArray.Length);
                     Array.Copy(bytEncriptado, keyArray.Length, encrypted, 0, encrypted.Length);

                     byte[] simKey = this._objRSA.Decrypt(keyArray, false);

                     return MiRijndael.Desencriptar(encrypted, simKey);
              }
              else
              {
                     return System.Text.Encoding.UTF8.GetString(this._objRSA.Decrypt(bytEncriptado, false));
              }
       }
}

Y el código del cliente público es el siguiente (declarado en algún lugar del formulario):

private miRSA _objKey = null;

public Form1()
{
       InitializeComponent();
       _objKey = new miRSA();
}

private void btnAsimEncriptar_Click(object sender, System.EventArgs e)
{
       byte[] _bytEncriptado = null;

       //Creamos una instancia del encritador publico
       RSACryptoServiceProvider _objEncriptadorPublico = new RSACryptoServiceProvider();
       //Le asignamos la llave genarada
       _objEncriptadorPublico.FromXmlString(this.txtAsimLlavePublica.Text);

       if (this.chkSimetrica.Checked)
       {
              //Se declara la memoria para almacenar la llave utilizada por nuestro Rijndael personalizado
              byte[] _bytKey = (Rijndael.Create()).Key;

              //Se encripta el texto y se obtiene la llave que se utilizó para la encriptación
              byte[] _bytEncriptadoSimetrico = TransEncripHash.MiRijndael.Encriptar(this.txtAsimAEncriptar.Text, _bytKey);

              //Se encripta la llave con el algoritmo RSA
              byte[] _bytEncriptadoLlave = _objEncriptadorPublico.Encrypt(_bytKey, false);

              //Se copia en un arreglo la llave encriptada y el encriptado de Rijndael
              _bytEncriptado = new byte[_bytEncriptadoLlave.Length + _bytEncriptadoSimetrico.Length];
              _bytEncriptadoLlave.CopyTo(_bytEncriptado,0);
              _bytEncriptadoSimetrico.CopyTo(_bytEncriptado, _bytEncriptadoLlave.Length);
       }
       else
       {
              _bytEncriptado = _objEncriptadorPublico.Encrypt(System.Text.Encoding.UTF8.GetBytes(this.txtAsimAEncriptar.Text), false);
       }
       this.txtAsimEncriptado.Text = Convert.ToBase64String(_bytEncriptado);
}

private void btnAsimDesEncriptar_Click(object sender, System.EventArgs e)
{
       this.txtAsimDesEncriptado.Text = this._objKey.DesEncriptar(Convert.FromBase64String(this.txtAsimEncriptado.Text), this.chkSimetrica.Checked);
}

private void btnAsimGenerar_Click(object sender, System.EventArgs e)
{
       this.txtAsimLlavePublica.Text = this._objKey.ObtenerLlavePublica();
}

En este ejemplo, la encriptación se produce en un lugar, luego de solicitar la clave pública a la clase (pero que perfectamente puede ser un servicio Web), la información encriptada se puede enviar a este servicio Web sin problemas de violación de seguridad, y sin necesidad de conocer ambas llaves. Si bien es cierto que la clase o servicio conoce ambas llaves, la llave pública no le es de ninguna utilidad.

Antes de finalizar con este algoritmo, cabe mencionar que donde puede haber problemas es en la generación de la llave. Por eso, Diffie-Hellman (& Merkle) se especializa en mejorar ese proceso, ya que es de vital importancia la generación de llaves.

Nota: Existe cierta codificación que puede haber pasado desapercibida hasta ahora. Esta es la utilización de distintos métodos para transformar textos en arreglos de bytes, y viceversa. Los métodos reales para hacerlo son los que están implementados en los encodings de .NET, como por ejemplo System.Text.Encoding.UTF8.GetString(bytes) y System.Text.Encoding.UTF8.GetBytes(string). En las demos se ha cambiado algunos deliberadamente por Convert.ToBase64String(bytes) y Convert.FromBase64String(string) para poder desplegarlo en los controles del formulario Windows. El resultado de una encriptación genera carácteres visibles y no visibles. Si no se transforman a Base64 y desde Base64 mientras son almacenados en un control, se pierde información. Si el resultado de la encriptación no va a ser desplegado sino que será almacenado en algún medio, los bytes de éste pueden escribirse sin problemas en el medio que sea.

Hash

Por último, nos quedan los algoritmos de tipo Hash. Estos son algoritmos del tipo de los que se conocen como de sólo ida, ya que no es posible desencriptar lo que se ha encriptado. Puede ser que a primera vista no se le vea la utilidad, pero en los siguientes dos escenarios éste es el tipo de algoritmo necesario para realizar el proceso. El primero de ellos está dirigido a proteger información muy valiosa encriptando el contenido; y el segundo busca validar que no se modifique la información que se está enviando desde un lugar a otro.

Escenario 1: Almacenar contraseñas de un sistema. Las contraseñas de cualquier sistema serio jamás debieran poder desencriptarse. El motivo es simple. Si se pueden desencriptar, el riesgo de que alguien conozca la llave y tenga acceso a todo el sistema con todos los usuarios es muy grande. Entonces, si no puedo desencriptar una contraseña, ¿Cómo puedo saber entonces si una contraseña entregada es válida? La respuesta es muy simple. Se encripta la contraseña entregada y se compara el resultado de la encriptación con la contraseña previamente almacenada.
Escenario 2: Validar que cierta información no se haya modificado. Si se desea enviar un bloque de datos y se quiere estar seguro de que nadie lo ha modificado durante el camino, lo que se hace es enviar el bloque de información sin encriptar y además se envía un Hash/Digest de este mismo bloque de datos. Entonces, nuestro receptor al tener la información sin encriptar, le aplica un Hash y con el mismo criterio del Escenario 1, determina si ambos bloques son iguales. Si lo son, el bloque que no está con Hash es el original. ¿Porqué no usar un algoritmo de encriptación reversible? Porque éste podría ser desencriptado, modificado y vuelto a encriptar y el receptor jamás sabría que fue modificado en el camino. Como el Hash no es reversible, esto último no podrá suceder jamás.

Los algoritmos para hacer Hash mas conocidos son los siguientes:

Algoritmo	Tamaño del Hash (bits)
MD5	128
SHA-1	160
SHA-256	256
SHA-384	384
SHA-512	512

La robustez de un algoritmo de Hash es comparable a la mitad del largo del resultado en bits. Entonces, pensar que con MD5 se está seguro puede ser un error. SHA-256 es el indicado para obtener seguridad de 128 bits. Es un hecho que SHA-256 es mucho más lento, pero como Bruce Schneier dice “Ya existen suficientes sistemas rápidos e inseguros”.

Pero a pesar de parecer muy efectivo, existe un problema con el Hash para cada uno de los escenarios indicados anteriormente. Como son problemas conocidos, existen soluciones conocidas también. Revisemos ahora cada uno de los problemas y sus soluciones.

Problemas Escenario 1
Si bien el problema no está tan relacionado con el Hash, debido a la utilización de contraseñas de escasa dificultad, haciendo un ataque de fuerza bruta o por diccionario se podrían encontrar valores de Hash que coinciden con el Hash de las contraseñas almacenadas. Para esto se pueden ejecutar dos planes de acción independientes, pero obteniéndose el mejor resultado con la utilización de ambos.

La Solución 1 consiste en realizar varias pasadas de Hash sobre los datos, aplicándole el Hash al resultado del Hash anterior. Realizando esto varios cientos de veces (idealmente mil veces) podemos dificultar más el trabajo de un hacker. Más información de porqué se debe iterar muchas veces y las consecuencias de no hacerlo, la puedes encontrar en http://www.atrevido.net/blog/PermaLink.aspx?guid=12b1338b-171e-4692-850e-8f59ed12f24a .

La Solución 2 requiere agregar un texto adicional a la contraseña. Esto se conoce como Salt. Entonces, cada vez que un usuario cambie o esté validando una contraseña, hay que concatenarle a la contraseña este Salt y de ahí generar el Hash. De esta forma le agrega variación a las contraseñas pobremente definidas. Esta solución requiere un trabajo adicional ya que es necesario además almacenar el texto del Salt junto a la información del usuario y la contraseña encriptada. Este texto se debe crear con carácteres generados al azar.

En el ejemplo se mostrará la combinación de ambas soluciones. Como encriptación de Hash se usará SHA256. Los otros algoritmos mencionados con anterioridad están disponibles también en .NET.

El resultado de la encriptación 1000 veces de cierto texto con un Salt definido, es el que se muestra en la figura 6:

Figura 6.

El código para realizar esto es muy simple y es el que se muestra a continuación:

public class HashContraseñas
{
       public static byte[] Encriptar(string strPassword, string strSalt, int intIteraciones)
       {
                                string _strPasswordSalt = strPassword + strSalt;
                                SHA256Managed _objSha256 = new SHA256Managed();
                                byte[] _objTemporal = null;

                                try
                                {
                                                _objTemporal = System.Text.Encoding.UTF8.GetBytes(_strPasswordSalt);
                                                for (int i = 0; i <= intIteraciones - 1; i++)
                                                                _objTemporal = _objSha256.ComputeHash(_objTemporal);
                                }
                                finally { _objSha256.Clear(); }

                                return _objTemporal;
       }
}

Qué cosas se deben clarificar en este proceso
El resultado de este Hash (Sha256) siempre retorna 256 bits, es decir, 32 bytes. Cuidado con confundir con el largo del string resultante de la conversión a Base64. Esta conversión genera más carácteres. Para verificar, puedes medir el largo del arreglo colocando un punto de interrupción en el retorno (return), y notarás que son 32 bytes.

Además, las funciones de hash no tienen limitante para el tamaño del texto de entrada. Sea cual fuere el tamaño, el largo de la salida es el mismo y se procesan todos los carácteres del string de entrada.

Para un sistema de almacenamiento de contraseñas de usuario seguro, hay que hacer algunas modificaciones a esta función, pero son mínimas. Las modificaciones no pasan por cambios en el algoritmo, sino más bien por crear una función para que genere Salt randómicos y crear la función para la comparación de las contraseñas.

Probablemente te preguntes porqué hay 2 cajas de texto con el mismo texto. Como este proceso es común, o al menos debiera serlo, .NET provee una clase llamada PasswordDeriveBytes que sirve para realizar de forma automática todo lo anteriormente visto. En el evento click, además de la llamada a la función detallada de más arriba (HashContraseñas.Encriptar), se crea una instancia de esta clase (PasswordDeriveBytes) y se le especifican los mismos parámetros que estamos utilizando en nuestro algoritmo de Hash (la contraseña, el Salt, el algoritmo SHA256 y la cantidad de iteraciones). Esto hace que en sólo pocas líneas se pueda realizar el mismo proceso.

El código ejecutado es el siguiente:

PasswordDeriveBytes _objPdb = new PasswordDeriveBytes(this.txtHashEncriptar1.Text, System.Text.Encoding.UTF8.GetBytes(this.txtSalt.Text), "SHA256", Convert.ToInt32(this.txtCantidad.Text));

this.txtHashEncriptado2.Text = Convert.ToBase64String(_objPdb.GetBytes(32));

Para comparar arreglos de bytes, se verá más adelante una función con tal objetivo.

Problemas Escenario 2: Si alguien puede ejecutar un Hash sobre un conjunto de datos y obtener el resultado, ¿Porqué no podría modificar el contenido del documento que estamos enviando y generar el Hash nuevamente, reemplazando el contenido del Hash anterior? ¿Cómo se puede diferenciar mi proceso de Hash del proceso de Hash impostor? No es posible a menos que haya alguna llave de por medio.

Debido a lo anterior, se han inventado los siguientes algoritmos de Hash, que utilizan llaves para realizar el proceso. En este caso, si el resultado se sobrescribe, al obtener el Hash con la llave, el resultado jamás coincidirá con el que viene en el mensaje.

Estos algoritmos y sus llaves son los siguientes:

Algoritmo	Tamaño del Hash (bits)	Tamaño de llave (bits)
HMAC-SHA1	160	64
MAC-3DES-CBC	64	8, 16, 24

Para realizar la demo, debemos primero generar una llave. Hasta ahora, las llaves se han creado manualmente, pero ahora vamos a utilizar herramientas del Framework para generarlas. Como la llave de 64 bits es del mismo largo que la que utiliza el algoritmo DES, se utilizará la clase de éste para generar una. Existe el botón “Generar Key” que es el encargado de generar y almacenar una llave. Esta se genera en la función del botón, y se almacena en una variable de formulario. El código es el siguiente:

privatevoid btnHashKey_Click(object sender, System.EventArgs e)
{
this._objHashKey = (new System.Security.Cryptography.DESCryptoServiceProvider()).Key;
this.lblSalt.Text = "Key : " + Convert.ToBase64String(this._objHashKey);
}

Con la primer sentencia se crea la instancia del proveedor de DES y se obtiene el Key almacenándolo en _objHashKey, una variable de formulario. Con la segunda línea, se copia el contenido de la Key en una etiqueta del formulario, previamente transformándolo en Base64. Cabe mencionar que la transformación a Base64 genera una cadena más larga que la cantidad de bytes que está recibiendo, por eso si cuentas la cantidad de carácteres del Key, no cumple con ser de 64 bits (8 bytes).

La validación es muy simple de realizar. Recuerda que lo que se quiere hacer es verificar que la información que se está enviando no se haya modificado en el camino. Entonces lo que se debe hacer es generar un nuevo Hash con el texto en cuestión y la contraseña, y comparar el resultado del Hash generado con el que se envió inicialmente. La comparación de Hash se realiza con una función para comparar arreglos (Ver figura 7):

Figura 7: Resultado de presionar Validar Hash sin hacer ninguna modificación.

En cambio, si se modifica levemente el texto, agregando la palabra "me" (o cualquiera) en el círculo rojo remarcado, y se trata de validar, el resultado es erróneo inmediatamente. Con esta funcionalidad se valida que nadie haya modificado el contenido de lo que se está enviando (Ver figura 8):

Figura 8: Resultado de presionar Validar Hash con una modificación.

Además, si se genera una nueva Key (con el botón Generar Key) y se valida, el resultado es fallido, como era de esperarse. Existe otro método para realizar esta misma validación pero sin compartir las llaves. La idea es muy similar a la estudiada en los algoritmos asimétricos, en donde una de las partes tiene una llave para encriptar y otra parte tiene otra llave para encriptar también. Algo similar a esto es lo que se utiliza para la firma digital, pero por ser un tema tan amplio, no cabe en este artículo y merece un artículo completo para su explicación. Algunas claves para poder conocer como funciona esto, las siguientes clases del Framework poseen funcionalidad para lograrlo. Estas son RSACryptoServiceProvider y DSACryptoServiceProvider. Por último, algo de código. Para generar un Hash con un Key y para comparar arreglos de bytes se utilizan los siguientes bloques de código:

public class HashValidacion
{
       public static byte[] Encriptar(string strTexto, byte[] objKey)
       {
              HMACSHA1 _objHMACSHA = new HMACSHA1(objKey);
              try
              {
                     return _objHMACSHA.ComputeHash(Encoding.UTF8.GetBytes(strTexto));
              }
              finally
              {
                     _objHMACSHA.Clear();
              }
       }

       public static bool CompareByteArray(Byte[] arrayA, Byte[] arrayB)
       {
              if (arrayA.Length != arrayB.Length)
                     return false;

              for (int i = 0; i <= arrayA.Length - 1; i++)
                     if (!arrayA.Equals(arrayB))
                           return false;
              return true;
       }
}

Conclusiones

A través de las dos partes de este artículo se han explorado los métodos más comunes de encriptación, revisándose cada escenario donde se aplican. Cada escenario se ha complementado con ejemplos y código 100% funcional. Se ha desmitificado la encriptación como un proceso complicado y nebuloso, mostrándose de forma clara cuándo y cómo aplicar cada algoritmo, además de la forma correcta de hacerlo.

Respuestas a las Preguntas

Revisemos entonces algunas de las preguntas inicialmente planteadas y veamos cómo podemos responderlas ahora.

¿Se está almacenando la información crítica de forma segura?
Esta pregunta la puede respnder el lector.

¿Qué entendemos por seguro?
Se ha mostrado la diferencia entre algoritmos que transforman texto con respecto a otros que realmente encriptan.

Si se está encriptando, ¿Qué algoritmo se está utilizando?
Se revisaron los algoritmos más conocidos y se mostraron sus ventajas y falencias. Sea cual fuere, el algoritmo debe implementarse adecuadamente.

¿Se permite la desencriptación de datos que no debieran poder desencriptarse?
Esta pregunta la puede responder el lector, pero la respuesta debe ser NO.

¿Cómo está realizándose la encriptación?
Se revisó la forma correcta de encriptar con cada algoritmo, como también las malas prácticas y los riesgos que se corren al no hacer el proceso como debe ser.

¿Dónde están almacenadas la o las llaves?
Esta es una muy buena pregunta y la respuesta escapa al alcance de este artículo, pero como sugerencia se puede mencionar lo siguiente: se puede utilizar DPAPI o Certificate Storage. Para implementar DPAPI tanto desde aplicaciones Windows como web, puedes visitar los siguientes enlaces:

DPAPI: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/SecNetHT07.asp
DPAPI en Web: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/SecNetHT09.asp
Pensamientos como el siguiente no son seguros: "si almaceno la llave en un directorio escondido, es difícil que un hacker la encuentre", como así también "A un hacker le va a tomar mucho tiempo encontrarla." Si hay algo que le sobra a un hacker es tiempo y ganas.
¿Con qué frecuencia se cambian las llaves?
La respuesta es depende, lamentablemente. Depende de la criticidad del sistema, como también del uso de las llaves. Para una conexión de transferencia, se crean las llaves, se utilizan y se descartan. En un sistema crítico tal como el de un banco, el cambio de llaves debería hacerse cada una hora, o como máximo, cada un día. Para información que va a tener mayor duración, el tiempo puede ser mayor.

¿Cómo enfrento el problema de cambiar las llaves con tanta frecuencia?
Como cambiar las llaves no es una tarea simple en recursos y tiempo, se emplea el concepto de llave maestra y llaves hijas. La información a encriptar se encripta con las llaves hijas y luego con la llave maestra se encriptan las llaves hijas y se almacenan. Entonces, al momento de aplicar cambio de llave, se cambia sólo la llave maestra, procediéndose a desencriptar todas las llaves hijas con la antigua y a encriptar todas con la llave nueva. Esto disminuye el tiempo a factor de N (cantidad de llaves) y no de la cantidad de bytes de información encriptada. Esto no agrega seguridad, sólo ayuda a realizar un proceso de forma eficiente.

¿Con qué criterio se definen las nuevas llaves?
Para definir una llave se puede ejecutar la función GenerateKey() que todo algoritmo simétrico posee. Esto genera una llave randómica.

Contadores de rendimiento de aplicaciones de 32 bits en sistemas de 64 bits

pmackay — Tue, 13 Nov 2007 23:03:00 GMT

Durante el análisis de Microsoft.VisualBasic.dll tuve problemas para poder ver los contadores de rendimiento de la aplicación desarrollada con Visual Studio 2003 y que se ejecutaba sobre el Framework 1.1, en un sistema XP 64 bits.

En ese momento inferí que podría deberse a que la aplicación estaba compilada para 32 bits y se estaba ejecutando en un sistema de 64 bits. Es conveniente recalcar que el Framework 1.1 compila ensamblados sólo para 32 bits.

Hoy, después de un tiempo, me tope con el KB 922775. Para mi sorpresa, tiene un punto dedicado al problema que se me presentó (You cannot monitor 32-bit managed programs in the 64-bit version of Perfmon). En éste, se presenta un workaround para poder monitorear contadores de rendimiento de aplicaciones de 32 bits corriendo en sistemas de 64 bits.

Además tiene información relevante para reconstruir los contadores si alguna vez se corrompen.

Saludos,
Patrick

Predicando con el ejemplo

pmackay — Mon, 29 Oct 2007 23:28:00 GMT

Predicar con el ejemplo. Hemos escuchado eso desde chicos. A veces es difícil lograrlo, pero el hacerlo trae beneficios de diferente índole.

El tema de esta oportunidad está relacionado con los mensajes de error. Uno de los tantos posibles problemas de seguridad de las aplicaciones es la revelación de más información de la necesaria cuando se produce un error.

Lo anterior significa que si la aplicación se cae, le informe al usuario pero no le dé mayor información al respecto, información que además es inútil para el usuario ordinario, pero útil para quien te quiera atacar.

Más información de esta vulnerabilidad podrán encontrar en el sitio del proyecto OWASP, en el siguiente link.

Hace un par de días estaba utilizando OWA de la empresa donde trabajo y de pronto, me topo con esta ventana. Haz clic en ella para verla completa.

Mal, mal. A predicar con el ejemplo. OWA no debiera mostrar este tipo de ventanas de error.

Buenos ejemplos

Veamos algunas pantallas de error donde sí se han tomado las precauciones.

Esta es la de la aplicación que utilizamos en el blog de msmvps.com. Muy divertida, aunque el administrador podría sentirse ofendido.

Google también cumple con las buenas prácticas.

Malos ejemplos

El típico error de asp.net, cuando el desarrollador y administrador no han tomado las medidas necesarias para que no le llegue al usuario final.

y para el final, el peor de todos, cuando se cae leyendo el archivo de configuración y se muestra el contenido de éste.

Corrección

¿Cómo corregirlo? Muy fácil.

Para que no se muestre el error en ASP.NET se puede utilizar el elemento Error en la configuración. Más información en este link: http://msdn2.microsoft.com/en-us/library/s2f4e3e7.aspx.

Para modificar IIS para que no muestre el contenido en los errores no controlados se pueden seguir los pasos detallados en este KB: http://support.microsoft.com/kb/302570/en-us

Saludos,
Patrick

Se viene un momento histórico...

pmackay — Sat, 20 Oct 2007 14:05:00 GMT

Es cosa de meses; ¿Cuántos?, ¿dos? ¿tres?, no sé, pero falta poco para un momento histórico. Más sitios corriendo sobre IIS que sobre ningún otro servidor web.

La información de Netcraft muestra para el mes de octubre lo siguiente.

Solo un 10% de diferencia entre sitios corriendo Apache e IIS. Considerando una tasa promedio de los últimos 3 meses, en donde IIS sube un 1,41% mensual y apache baja un 1,65% mensual, debiera invertirse la situación en un poco mas de tres meses. Google podría tener algo que decir también.

En tres meses más lo vemos

Los meses anteriores mostraron esta información, para agosto y septiembre respectivamente.

Saludos, desde Santiago de Chile
Patrick

Pantallas Azules, ¿hasta cuando?

pmackay — Mon, 15 Oct 2007 18:33:00 GMT

Seguramente al leer el título de este post pensaste en que me voy a referir a las pantallas azules de Windows. Correcto. También puedes haber pensado que es un post para criticarlas. Bueno, eso no será así. Este post tiene como objetivo explicarlas.

Historia

Hace ya un par de años, leí un recorte en el típico mural de las empresas, que estaba escrito por alguien conocido por mí y un referente nacional en muchos aspectos.

El artículo escrito se llamaba "El software nuestro de cada día" y estaba escrito por José Miguel Piquer.

Jo y Microsoft

José Miguel, o "Jo" como le dicen los más cercanos, fue profesor mío en algunos cursos en la carrera de "Ingeniería Civil en Ciencias de la Computación e Informática," en la Universidad de Chile.

Siempre un gusto ir a sus clases, magister, doctorado y varios títulos más que pueden leer en su página personal del Departamento de Ciencias de la Computación (DCC), le recuerdo como acérrimo detractor de Microsoft y Windows.

Artículo

Bueno, el inicio del artículo escrito por él, esboza la siguiente frase:

Hay que aceptar que resulta extremadamente frustrante enfrentarse a sistemas que se caen: desde las pantallas azules clásicas de Windows, pasando por los sitios webs bancarios que no responden, hasta las agendas y sus fatal exceptions que se están volviendo más norma que excepción.

Después, el artículo va realmente a lo importante que él quiere exponer, pero con ésta introducción cae lamentablemente en facilismos con una frase que no aporta mucho, más que exacerbar el cuento de "nunca acabar" de las pantallas azules.

El artículo está escrito en julio del 2005, diez años después del festín de pantallas azules que nos daban Windows 95, Windows 98, Windows 98 segunda edición y finalmente (por suerte!) Windows Millenium Edition.

En mis años de estudiante (93-99) nunca hubo un PC en la universidad (salvo el de la secretaria del DCC), así que dudo que él personalmente se haya enfrentado a un sistema de estos, aunque no es por ahí donde quiero llevar este post.

Profesor, todos esperamos mucho de usted. Por favor, no caiga en frases fáciles. No las necesita. Usted está lejos de ser un político.

En el año 2005, ya existía Windows 2003, sistema operativo que casi no presentaba pantallas azules. Más aún, en 4 años, no recuerdo haber visto una pantalla azul en Windows 2003, experiencia que seguramente tú compartes.

¿Son las pantallas azules exclusivas de Windows?

Casi. En los otros sistemas operativos no son necesariamente azules.

Pantallas azules de diferentes sistemas operativos

Hagamos una revisión de las pantallas y los sistemas operativos.

Tenemos la clásica de Windows 9X.

¿Mac OS?, por supuesto que sí, aunque tienen una diferencia con las de Windows. Son más bonitas y mejor logradas, pero el mensaje no dice nada útil, y que el usuario no pueda intuir que tiene que hacer.

Bueno, no siempre son bien logradas, aunque el mensaje es de mayor utilidad que la pantalla anterior.

¿Linux?, claro que sí, en variadas distribuciones, aunque son llamadas Kernel Panic (un nombre más realista para el problema que analizaremos más adelante).

¿Quién esté libre de pecado...

...que lance la primera piedra?, o como dice mi amigo Luisón, el sol sale para todos, y la noche también.

Como ven, no hay sistemas operativos sin fallas, aunque Apple crea y venda lo contrario. Todos enfrentan los mismos problemas. Apple tiene una ventaja en este aspecto sobre Microsoft, la cual se minimizará en el tiempo, mientras se pueda instalar Windows Vista o XP sobre hardware homologado por Apple.

Además, es cosa de leer foros para darse cuenta de que Apple funciona bien con software Apple. Cuando empiezas a instalar software de terceros que no cuentan con buenos procesos de certificación, la situación se equipara.

Vamos a la teoría

Considerando la arquitectura de procesadores x86, en el año 1982, con el lanzamiento del 80286, se comienzan a dar los primeros pasos en lo que hoy se conoce como protected mode.

Protected mode, provee dentro de un conjunto de características, la existencia de cuatro niveles de privilegio, conocidos también como anillos (rings), numerados desde el 0 al 3.

El anillo 0 tiene acceso irrestricto a todo. El anillo 3 tiene accesos restringidos y acotados. El anillo 1 tiene más restricciones que el 0, pero menos que el 2 y menos que el 3 obviamente.

Anillos y Windows

Hoy en día, un sistema Windows 2003 ejecuta código en dos anillos. El 0 y el 3. También corre para XP y 2000. Tengo entendido que Vista utiliza el 0, 2 y 3, pero no lo puedo garantizar.

En el anillo 0 se ejecuta el Kernel de Windows, el cual realiza algunas de las actividades listadas a continuación. Administración de memoria, acceso al hardware a través del HAL, acceso a dispositivos utilizando drivers, priorización de actividades, plug and play, acceso a redes utilizando protocolos como TCP/IP o HTTP, etc.

En el anillo 3 se ejecutan las aplicaciones. Cada vez que una aplicación necesita de alguno de los elementos anteriormente mencionados, y que maneja el Kernel, necesita solicitárselo a éste ya que la aplicación no tiene permiso para acceder directamente.

Esta solicitud y cambio de contexto entre la aplicación y el Kernel tiene un costo, el cual fue tratado de minimizar en el pasado, pero las lecciones aprendidas fueron duras.

¿Por qué se producen?

Una pantalla azul en Windows se produce cuando se produce una falla en código que se ejecuta en el Kernel.

Si una aplicación se cae (anillo 3), nuestro amigo Dr. Watson la atiende y la mata, pero el sistema operativo sigue funcionando sin problema. Hoy en día, Windows te pregunta si deseas enviar el reporte de error a Microsoft, utilizando la aplicación Windows Error Reporting.

Si el Kernel falla (anillo 0), no hay remedio ni doctor que te salve. Bueno, Dr. Watson no salvaba las aplicaciones sino que les aplicaba la eutanasia. Con un Kernel con alguna excepción, no se puede seguir funcionando. Cualquier intento (teórico) de seguir funcionando podría implicar que se corrompan archivos en el disco, por ejemplo.

Mencionaba hace un rato que en Linux, la pantalla azul se llama Kernel panic. En efecto, eso es. Es un problema en el Kernel y no hay mucho más que hacer, salvo entrar en pánico.

En los SO Windows de hoy, versión 2000 en adelante, los motivos de las pantallas azules son los siguientes. Este gráfico fue generado con datos hasta el mes de Abril del 2004, obtenido del libro Windows Internals de Solomon y Russinovich.

El 15% desconocido se debe a que el nivel de corrupción en la información obtenida después de la caída es tan grande que no permite identificar ningún responsable.

Windows 9X y el festín de las pantallas azules

Por algún motivo de diseño, que jamás sabremos el origen, debido al costo del cambio de transición entre el anillo 3 y el 0, los diseñadores de ese sistema operativo consideraron que para mejorar el rendimiento, mucho código del sistema y aplicaciones correrían en el anillo 0.

Debido a esto, el más mínimo error en cualquier aplicación, podría comprometer el sistema completo, como ocurrió en la archiconocida presentación de Windows 98 de Bill Gates.

Esa fue una lección de duro aprendizaje.

Drivers

Como se pudo ver en el gráfico, el 70% de los problemas son producto de drivers de terceros que corren en el Kernel, y sólo el 5% es código defectuoso de Microsoft. Me gustaría saber cuál es la tasa actual, al final del 2007.

Cuando nosotros como usuarios instalamos un driver que no está certificado, estamos generando un potencial problema con nuestro computador. Por supuesto, ese driver puede estar muy bien desarrollado y jamás tendremos una pantalla azul.

En mi caso particular, el driver de mi webcam tiene problemas serios en Windows XP 64 bits. En Windows XP 32 bits funciona sin problema. En 64 bits, cada vez que abro el Messenger y la activo, pantalla azul. ¿Puede ser Messenger el responsable de la caída de mi equipo? Claro que no. Messenger corre en el anillo 3, pero el driver de mi webcam corre en el 0.

Windows Vista

Según tengo entendido, en Windows Vista, algunos o todos los drivers de terceros se ejecutan en el anillo 2, es decir, con mayor privilegio que las aplicaciones, pero con menor privilegio que el Kernel. Esto ayudaría enormemente a minimizar los problemas de pantallas azules producto de drivers defectuosos. Ya sabemos que para abril del 2004, el 70% de los errores reportados era por problemas de drivers defectuosos.

Parte de ésta información se puede encontrar aquí (sección Driver stability in Windows Vista), pero nada menciona de anillos. Sí menciona que parte del driver corre a nivel de usuario (anillo 3).

Ventaja de Apple

Apple tiene una gran ventaja sobre Microsoft, sin embargo, la posibilidad de instalar Windows sobre un equipo Apple mostrará nuevos aspectos en esta materia.

Como sabemos, el gran problema de Windows son los drivers de terceros.

Windows está hecho para que funcione sobre casi cualquier hardware que sea x86, x64 e IA64 compatible. Como hardware me refiero a placas madre, tarjetas de video de dudosa procedencia, memoria de dudosa procedencia, procesadores de segunda generación de Intel, tarjetas de red y cuanto hardware se pueda construir en el mundo.

Por otra parte, el hardware de los equipos Apple está homologado, probado y garantizado para que funcione bien, como piezas de una buena orquesta.

¿Qué sucede si quiero expandir la memoria de mi Apple? tengo que ir a Apple e instalar la que ellos dicen que funciona.

¿Qué sucede si quiero expandir la memoria de mi PC?. Voy y compro en la esquina la más económica.

Lo mismo para el resto del hardware, y por ende, los drivers.

Drivers malos, problemas de Kernel. Problemas de Kernel, pantallas azules.

Mi amigo Luisón ya instaló Vista en su Mac (también tiene un PC) y dice que anda mucho mejor que en el PC. Yo no puedo atestiguarlo, pero le creo.

Anillo 1

Antes de finalizar, una nota anecdótica. El anillo 1 estuvo mucho tiempo sin utilizarse, o al menos eso es lo que yo tengo entendido. Sin embargo, en estos últimos años se ha usado bastante, aunque probablemente no sepas cómo.

Si utilizaste Virtual Server o Virtual PC, las máquinas virtuales se ejecutan en el anillo 1. Esto significa que tienen más privilegios que tus aplicaciones, pero menos que el Kernel del sistema operativo host. Así, una maquina virtual no podrá hacer caer tu sistema operativo de host.

¿Anillo -1?

Otra nota curiosa. En hardware que soporta virtualización, quien controla la administración de las máquinas virtuales (Hypervisor en Windows 2008) se ejecuta en el anillo -1, para que las máquinas virtuales se ejecuten en los anillos correspondientes a como ha funcionado siempre (0 y 3). Más información en Ponicke Bloguea.

Espero haber arrojado un poco más de luz sobre el cuénto de nunca acabar de las pantallas azules.

Todos los sistemas operativos mencionados las tienen, y en todos el problema es el mismo.

Saludos, desde Santiago de Chile
Patrick

¿Expresiones regulares?...¿una ayuda por favor?

pmackay — Thu, 04 Oct 2007 19:46:00 GMT

Si hoy tuviese que dar una lista de las funcionalidades más poderosas de cualquier lenguaje y que son menos usadas, sin duda incluiría en esta lista las expresiones regulares.

Hay que ser honestos y reconocer que existen un par de barreras de entrada importantes para su uso.

Documentación. No existen muchos sitios dedicados a explicarlas. Hay unos muy buenos, pero son pocos.
Dificultad de aprendizaje. No son triviales.

Si tienes conocimientos básicos de estas y siempre has tenido problemas probando y probando, te recomiendo este sitio. Tiene un probador que usa colores y te muestra si tu información cumple con la expresión definida, y si no lo hace, hasta dónde llega.

La URL es regexpal.com y ésta es una imagen de su utilización. Muy útil.

Microsoft.VisualBasic.dll, ¿Eres tan malo como dicen?

pmackay — Thu, 27 Sep 2007 01:16:00 GMT

Algunos años atrás, todo lo relacionado con Visual Basic (VB) 6.0 tendía a ser menospreciado o subvalorado. Los desarrolladores que utilizábamos VB 6.0 no éramos los primeros en levantar la mano para decir orgullosos que lo utilizábamos, como sí lo hacían los que usaban C o C++.

Una pequeña fracción de esa baja estima se mantuvo aún cuando apareció .net. Era cierto que teníamos un nuevo lenguaje (o un lenguaje muy remozado) que permitía lograr cosas impensadas en VB 6.0, tales como programar realmente orientado a objetos, crear threads, o deshacernos por fin de los problemas de los componentes marcados como Apartment, pero seguía existiendo "algo."

A mi entender, algunos de los problemas que NO ayudaron a la transición real de un lenguaje limitado a un lenguaje completo, se pueden desglosar en la siguiente lista:

La existencia Option Explicit en vb.net. No existe programación seria sin declaración e inicialización de variables.
La existencia de Option Strict en vb.net.
Microsoft.VisualBasic.dll, librería para ayudar a la migración de proyectos, que implementa esas terribles funciones como Len, Left, Right, Trim, Mid, Replace y otras.

Respecto a este último punto, siempre que tenía la dicha de ver algún proyecto usándola, terminaba recomendado que no se use y que use las propiedades de los tipos de .net. (Ej: en vez de usar Len(variable) usar variable.length).

Ante la obvia pregunta de ¿por qué no debo usarla?, venía una respuesta que obtuve de variados lugares, pero nunca comprobé empíricamente, y que sostenía que tenía menor rendimiento que las nativas de los tipos.

A veces incluso utilizaba Reflector para justificar mi teoría, como muestro en la siguiente imagen. ¿Para qué usar Trim(variable) si al final lo que se ejecuta es variable.trim? Mejor hacerlo directamente.

En esta oportunidad he decidido hacer pruebas sobre las funciones más utilizadas de VB 6.0, pero que fueron reescritas en este ensamblado (Microsoft.VisualBasic.dll) y determinar bajo pruebas empíricas si son "tan" malas como aparentan.

Quiero hacer hincapié en algo muy importante. Las funciones antes mencionadas, implementadas en VB 6.0, y que califiqué como "terribles", justifican el calificativo asignado. Muchas de ellas, si es que no todas, reciben como parámetro de entrada un tipo de datos variant y retornan un tipo variant.

Esta conversión a variant penaliza el rendimiento de la aplicación, y peor aún, si se realiza en en ambos sentidos (entrada y salida). Siempre hablando en el contexto de VB 6.0, algunas funciones tenían variantes que terminaban en $, como Left$, y que tenían la gracia de retornar un tipo string, pero seguían recibiendo un variant. No entiendo que costaba hacer una que recibiese string y retornase string, pero ya está. Ya fue.

Por suerte, ahora en .net, las implementaciones en Microsoft.VisualBasic.dll incluyen parámetros correctamente tipificados, con la consecuente mejora en rendimiento.

Vamos a la prueba y a los sorprendentes resultados.

Código a ejecutar

Todas las funciones a medir fueron llamadas desde una única función general para cada lenguaje, llamadas ProcesarComoVB6 y ProcesarComoVBNET. No es mi intención medir y comparar el rendimiento de cada función específica sino que medir en general que sucede si se utilizan funciones de Microsoft.VisualBasic.dll o las nativas de los tipos en forma directa.

Cada función general recibe una cadena de 41.000 bytes y la procesa siguiendo la misma regla, detallada en el código de más abajo.

El siguiente es el código a ejecutar, utilizando Microsoft.VisualBasic.dll

El mismo código, utilizando las llamadas nativas de los tipo

La prueba comprende la ejecución una cantidad de 200 veces cada una de las funciones, midiendo los tiempos en terminar de procesar todas las instrucciones. Antes de iniciar las 200 iteraciones de cada una de las funciones, estas son llamadas un par de veces antes para JITtearlas (bonita palabra, no?)

Resultados de las pruebas

Ejecutando la prueba en un proyecto desarrollado en Visual Studio 2003 con el Framework 1.1, compilado en modo release, se obtienen los resultados de la siguiente tabla:

Ejecución N°	Microsoft.VisualBasic.dll	Métodos nativos
1	28,51 segundos	16,20 segundos
2	27,76 segundos	16,15 segundos
3	30,45 segundos	17,40 segundos

Wow...(no estoy haciendo propaganda a Vista ), impresionante. No nos engañemos todavía. Aún hay mucho que descubrir.

Analicemos antes de seguir las funciones que estamos midiendo y qué podría justificar la diferencia.

Tanto Left, Right como Mid debieran tener costos similares a la representación en VB.NET utilizando Substring. Técnicamente lo que hacen es obtener un grupo de caracteres de una cadena. No hay mucha ciencia.

Conversiones de caracteres a números y viceversa no son costosos, o no debieran serlo. Entonces, Convert.ToChar y Convert.ToInt32 debieran tener similar rendimiento a Asc y Chr respectivamente. Esto último no es necesariamente cierto para el resultado de la transformación. Los resultados de Asc y Chr pueden diferir de los de Convert.* de acuerdo a la cultura que se utilice.

¿Que nos queda?...Replace...el dolor de cabeza de un procesador....

Nuevas pruebas, sin Replace

El siguiente es el resultado de las pruebas removiendo el Replace del final, de ambas funciones. Los resultados son nuevamente sorprendentes.

Ejecución N°	Microsoft.VisualBasic.dll	Métodos nativos
1	7,59 segundos	7,46 segundos
2	9,20 segundos	8,73 segundos
3	8,98 segundos	8,07 segundos

Interesante, no? ¿Qué se puede concluir ahora?

Conclusiones aventuradas

Descartando la función Replace, como supusimos, no hay mucha diferencia en el tiempo entre utilizar el ensamblado Microsoft.VisualBasic.dll y las funciones nativas. Replace hace la diferencia. Veamos por qué.

Si se utiliza Reflector para ver el código de String.Replace se obtiene esto.

Si se utiliza Reflector para ver el código de Replace desde Microsoft.VisualBasic.dll, se obtiene esto, y pongan atención a la zona enmarcada en rojo. Ouch!! Eso afecta cualquier procesador.

Más aún, Strings.Split y String.Join son funciones implementadas en Microsoft.VisualBasic.dll y no las nativas del tipo string.

Consumo de recursos

Veamos ahora como anda el consumo de recursos y uso del procesador para cada ejecución. Para eso utilizaremos performance monitor y revisaremos contadores de CPU, proceso, excepciones en .net y memoria en .net.

Los contadores a medir son:

Uso del procesador para el proceso, tanto para tiempo de proceso de usuario como de kernel
Excepciones lanzadas por segundo
Colecciones en cada generación
Colecciones inducidas
Total de bytes utilizados
Bytes pedidos por segundo
Tiempo utilizado por el GC
Bytes privados del proceso

Grande fue mi sorpresa cuando los contadores de rendimiento de la memoria en .net, todos marcaban cero durante la ejecución. ¿El motivo? No se si es el motivo "oficial," pero al menos a mi me bastó como auto-explicación. El Framework 1.1 no corre de forma nativa en 64 bits ya que este sólo puede generar código ensamblado de 32 bits. Como mi sistema operativo es 64 bits, es posible que la instrumentación de 1.1 no funcione. Por lo tanto, a mover todo al Framework 2.0 y Visual Studio 2005.

Nota: Si te preguntas por que no hice todo el post utilizando 2.0, la respuesta es porque quería mostrar cual es el impacto de correr aplicaciones 32 bits sobre 64 bits emulando 32, tanto para el Framework 1.1 como 2.0. También haré la prueba con 2.0 compilado en 32 bits, que es lo que viene justo ahora.

Compilando para 32 bits (x86) una aplicación .net 2.0

En esta oportunidad no haremos mucho análisis. Me interesa dejar los tiempos como referencia y poder comparar en los diferentes ambientes.

Versión con Replace

Ejecución N°	Microsoft.VisualBasic.dll	Métodos nativos
1	23,32 segundos	25,15 segundos
2	23,29 segundos	25,16 segundos
3	23,28 segundos	25,46 segundos

Versión sin Replace

Ejecución N°	Microsoft.VisualBasic.dll	Métodos nativos
1	7,40 segundos	7,37 segundos
2	7,17 segundos	7,09 segundos
3	7,18 segundos	7,78 segundos

¿Conclusiones?...mmm, no gracias.. No tengo nada inteligente que aportar, como tampoco quiero hacer suposiciones. Full 64 bits por favor!!

Compilando para 64 bits (x64) una aplicación .net 2.0

Veamos los resultados de la misma prueba compilado para 64, o mejor dicho, compilado para cualquier CPU. Total, una vez que se JITtee (bonita palabra nuevamente, no?), lo hará para el procesador en que se está ejecutando.

Versión con Replace

Ejecución N°	Microsoft.VisualBasic.dll	Métodos nativos
1	14,07 segundos	19,35 segundos
2	13,98 segundos	18,79 segundos
3	14,25 segundos	19,12 segundos

Versión sin Replace

Ejecución N°	Microsoft.VisualBasic.dll	Métodos nativos
1	5,86 segundos	5,96 segundos
2	5,93 segundos	5,68 segundos
3	5,79 segundos	5,75 segundos

¿¿¿¿Qué????

Parece que el equipo de desarrollo de VB.NET se tomó en serio las críticas y decidieron mejorar el producto.

Veamos con reflector el código de Replace de Microsoft.VisualBasic.dll, para la versión 2.0 del Framework.

Interesante. Cambiaron esa idea de hacer splits y joins e implementaron una función con ese fin específico. ReplaceInternal utiliza un Stringbuilder para cumplir su labor. Bien.

Volvamos ahora que tenemos contadores al análisis del consumo de recursos.

Consumo de recursos, V 2.0

Analicemos la utilización de recursos para ambas versiones, con y sin Replace. En todos los contadores colocaré el valor por defecto, que en algunos casos es el promedio y otros el máximo.

Versión con Replace

Contador	Microsoft.VisualBasic.dll	Métodos nativos
# Exceptions Thrown/sec	0	0
# Gen 0 Collections	23.236	15.134
# Gen 1 Collections	2	61
# Gen 2 Collections	0	12
# Induced GC	0	0
# Total Commited Bytes	1,3 MB	3 MB
% Time en GC	7,1 %	2,8 %
Allocated bytes/sec	1,1 GB (así es)	512 MB
% User Time	89 %	85 %
% Privileged Time	3 %	12 %
Private Bytes	23 MB	24,8 MB

Mini conclusiones versión con Replace

La utilización de métodos nativos consume menos recursos en general. Hay una reducción importante en las recolecciones de primera generación (gen 0), pero las recolecciones en esa generación son muy económicas, al igual que las de la generación 1. Las de generación 2 son caras y hay que evitarlas, aunque 12 es un número pequeño.

Lo anterior se traduce en que la versión con métodos nativos consume menos procesador recolectando "basura," y genera mucho menos "basura" (Allocated bytes/sec).

En la versión con métodos nativos, podría existir una relación entre la cantidad de bytes commited y la cantidad de recolecciones de segunda y tercera generación (gen 1 y gen 2) ya que hay memoria que se mantiene ocupada más tiempo y no es liberada en recolecciones de primera generación. Esto es solo una suposición.

Versión sin Replace

Contador	Microsoft.VisualBasic.dll	Métodos nativos
# Exceptions Thrown/sec	0	0
# Gen 0 Collections	14.305	12.654
# Gen 1 Collections	0	52
# Gen 2 Collections	0	10
# Induced GC	0	0
# Total Commited Bytes	1,3 MB	3 MB
% Time en GC	9,3 %	8,2 %
Allocated bytes/sec	2,0 GB	1,5 GB
% User Time	93 %	94 %
% Privileged Time	4 %	4 %
Private Bytes	23,5 MB	25,9 MB

Mini conclusiones versión sin Replace

El consumo de recursos es equivalente. Llama la atención el aumento en ambas versiones de la cantidad de bytes pedidos por segundo (allocated bytes/sec).

El resto de los contadores no presenta diferencias importantes entre ambas funciones para la versión sin Replace.

Conclusiones

Las siguientes conclusiones puedo obtener del análisis.

1.- No correr aplicaciones 1.1 en 64 bits

2.- No correr aplicaciones compiladas para x86 en 64 bits

Tristemente, mi intención inicial de encontrar algún motivo para que no se utilice Microsoft.VisualBasic.dll en los proyectos no ha podido ser cumplida.

En el único escenario donde encarecidamente recomendaría no usarla es en aplicaciones 1.1, pero en aplicaciones 2.0, la diferencia es irrelevante.

Saludos,
Patrick.

¿Cómo reducir el costo de un LookUp de SQL Server?

pmackay — Sun, 09 Sep 2007 05:53:00 GMT

Durante la exposición de nuestra charla de como optimizar consultas de SQL Server, hice bastante hincapié en la relación/dependencia de los índices no agrupados (no clustered) y el agrupado (clustered) de un tabla. En caso de que ésta no cuente con un índice agrupado, existe una relación/dependencia similar pero con una estructura interna de la tabla (RID).

En este post veremos qué es un LookUp (SQL 2005) o Bookmark LookUp (SQL 2000) y cómo eliminarlos o al menos mitigarlos cuando se pueda. Usaré SQL 20005, pero si tienes 2000, la manera de enfrentarlo es similar.

Antes de ir a la información del caso, haremos un pequeño repaso de lo revisado en la charlas de optimización de consultas.

Relación/dependencia entre índices en una tabla

Un índice no agrupado almacena, por cada elemento del índice, un "identificador" que dice donde encontrar en la tabla los datos asociados a este ítem del índice. De esta forma, cada vez que SQL Server utiliza el índice no agrupado y determina que debe ir a buscar los datos, utiliza ese "identificador" para ubicar los datos en la tabla.

Si la tabla no tiene un índice agrupado, el identificador utilizado es el identificador de la fila o row id (en inglés), el cual se representa con las siglas RID. Este RID está compuesto por el numero del archivo de la base de datos, el número de la página dentro de ese archivo y por último, el número de la fila en la página.

Si la tabla sí tiene un índice agrupado, el identificador utilizado es la llave del índice agrupado. La llave del índice agrupado son TODAS las columnas del índice agrupado. Por favor, no confundir la llave del índice con la llave primaria de una tabla, aunque muchas veces tienen el mismo "valor," en especial cuando la tabla se creó sin darle mayor importancia a este tema.

Para más información, revisa el BOL (Books On Line) de SQL Server, en la instrucción Create Index.

Bookmark LookUp o LookUp a secas

En SQL Server 2000 se le conoce como Bookmark LookUp. En la versión 2005 se llama solamente LookUp. La idea es la misma para ambas versiones; El problema es el mismo, las soluciones similares.

LookUp, traducido al español, significa operación de búsqueda, y representa exactamente eso. Realiza una operación de búsqueda, con un "identificador" de una fila, para traer más información, de la fila específica, desde la tabla.

La búsqueda se hace, como ustedes se imaginan, utilizando el RID si la tabla no tiene un índice agrupado, o utilizando la llave del índice agrupado, si la tabla cuenta con uno de ese tipo. La siguiente imagen sirve para aclarar el concepto que se trata de explicar.

Utilizando el índice no agrupado, primero se identifica las filas que cumplen con la condición de filtrado.

Resultado: Celdas amarillas.

Se usan los tres identificadores de filas (rojo, verde y azul) y se realiza la operación de búsqueda en el índice agrupado.

Si la tabla no tiene índice agrupado, la operación es similar, pero usa el RID.

Se retornan los datos faltantes.

Veamos entonces ahora información del caso. En esta oportunidad reproduciré el escenario en una base de datos de prueba, con unas tablas creadas para la ocasión.

LookUp muy costoso

Nota: Hace un tiempo atrás estaba en un curso de optimización de SQL Server y le hice la siguiente pregunta a la instructora: "Si tengo el plan de ejecución de una consulta, y el operador de lookup es responsable de casi el 100% del costo del plan, ¿cómo puedo mejorar el rendimiento de mi consulta?."

Tristemente, no hubo una respuesta aclaratoria ante mi pregunta, como ocurrió en varias otras además. Hoy en día, retrospectivamente, pienso que la instructora era lo que nosotros acá en Chile llamamos "un Adán", de Adán y Eva. ¿Por qué?. Porque si a Adán le sacas la hojita, queda desnudo. En este caso, la "hojita" es el "libro del curso."

Si has estado tratando de optimizar consultas de SQL, es probable que ya te hayas topado con este problema. ¿Qué hacer cuando la operación LookUp es muy costosa?

Antes de comenzar, estructura de tablas

Para este ejemplo, utilizaremos dos tablas, t1 y t2, con la siguiente estructura cada una

CREATE TABLE [dbo].[t1](
    [c1] [int] IDENTITY(1,1) NOT NULL,
    [c2] [varchar](50) NOT NULL,
    CONSTRAINT [PK_t1] PRIMARY KEY CLUSTERED ([c1] ASC) ON [PRIMARY])
ON [PRIMARY]

CREATE TABLE [dbo].[t2](
    [c1] [int] IDENTITY(1,1) NOT NULL,
    [c2] [int] NOT NULL,
    [c3] [varchar](50) NOT NULL,
    [c4] [tinyint] NOT NULL CONSTRAINT [DF_t5_c4] DEFAULT ((1)),
    [c5] [char](200) NOT NULL CONSTRAINT [DF_t2_c5] DEFAULT (''),
    CONSTRAINT [PK_t2_1] PRIMARY KEY CLUSTERED ([c1] ASC) ON [PRIMARY])
ON [PRIMARY]

CREATE NONCLUSTERED INDEX [idx_c2] ON [dbo].[t2] ([c2] ASC)
ON [PRIMARY]

ALTER TABLE [dbo].[t2] WITH CHECK
ADD CONSTRAINT [FK_t2_t1] FOREIGN KEY([c2]) REFERENCES [dbo].[t1] ([c1])

La tabla t1 tiene 100.000 registros. La tabla t2 tiene 1.000.000 registros. La consulta que estamos realizando es la siguiente.

select t1.c1, t1.c2, t2.c1, t2.c3, t2.c4
from t2 inner join t1 on t2.c2 = t1.c1
where t2.c2 between 1000 and 2000 and t2.c3 like '2%' and t2.c4 = 1

Con esta consulta, estamos trayendo un cantidad importante de columnas de la tabla t2, como también las dos columnas de la tabla t1. Existe un índice en t2.c2, por lo tanto, el filtro between 1000 and 2000 se realizará utilizando el índice para reducir las filas.

El siguiente es el plan de ejecución generado, en versión texto y gráfico.

Table 't2'. Scan count 1, logical reads 30682, physical reads 0, ...
Table 't1'. Scan count 1, logical reads 6, physical reads 0, ...

Rows    Executes  StmtText
-------------------------------------------------------------------------------------------
561     1         |--Merge Join(Inner Join, MERGE:([test].[dbo].[t1].[c1])=([test].[dbo].[t
1001    1               |--Clustered Index Seek(OBJECT:([test].[dbo].[t1].[PK_t1]), SEEK:([  
561     1               |--Filter(WHERE:([test].[dbo].[t2].[c3] like '2%' AND [test].[dbo].
10010   1                    |--Nested Loops(Inner Join, OUTER REFERENCES:([test].[dbo].[t2
10010   1                         |--Index Seek(OBJECT:([test].[dbo].[t2].[idx_c2]), SEEK:(
10010   10010                     |--Clustered Index Seek(OBJE...]) LOOKUP ORDERED FORWARD)

Si miramos la versión gráfica, podremos observar que el 100% del costo del plan esta en la operación lookup. Notar que hemos marcado algunos textos en blanco arriba, los cuales revisaremos más adelante. Para ver el plan gráfico más grande, haz clic sobre él.

En el plan gráfico, podemos ver que la operación Key Lookup es responsable del 100% del costo de plan, con un costo de 22,06 (muy malo para un operador, y en consecuencia para el plan). Complementando con el plan de texto, en éste aparece la palabra LOOKUP, y está usando el índice agrupado (clustered) para recuperar las demás columnas que necesita.

Además, se realizan más de 30.000 lecturas sobre la tabla t2.

¿Donde está el problema?¿Por qué tiene un costo tan elevado?

Una única operación de LookUp es de bajísimo costo, más aún si utiliza un índice para hacer un seek a una fila específica en la tabla. Sin embargo, si se ejecuta 10.010 veces, la sumatoria de estos costos pequeñísimos pasa a tener relevancia, como es nuestro caso.

La cantidad de veces que se ejecuta la operación LookUp se puede ver en 2 partes. Una de ellas es el texto marcado con blanco en el plan de ejecución de texto y la otra es en el Tooltip amarillo, en "Actual Number of Rows."

Solución[es] al problema

Existen dos formas de enfrentar este problema, y por supuesto, dependen de cada escenario.

Una de ellas, y que no veremos ahora porque no tienen ninguna gracia, es agregar todas las columnas necesarias al índice, y con eso, evitar la operación LookUp. Si tengo toda la información en el índice, no necesito ir a buscar más columnas a la tabla. Esta no falla nunca, pero uno debe evitar incluir muchas columnas en los índices.

La segunda solución, y que es mucho más elegante, sólo es posible realizar en un escenario como el que tenemos ahora.

Si miran con detenimiento el plan de ejecución, el operador filter está filtrando en las columna c3 y c4, aplicando los criterios definidos en la consulta SQL. Esto es esperable.

Más aún, como resultado del filtrado, la cantidad de filas retornadas disminuye (anchos de las flechas de entrada y de salida del filter). Esto también es esperable, ¿o no?

Si todo es esperable, ¿dónde está la gracia?

El costo del operador LookUp es muy alto porque se ejecuta muchas veces, ¿verdad?. ¿Qué sucedería si logro reducir la cantidad de veces que deba ejecutarse? Seguramente el costo de la consulta será menor y el rendimiento de ésta mucho mayor.

Para reducir la cantidad de veces que se ejecuta, debo reducir la cantidad de filas que son retornadas luego de que se filtre utilizando el índice idx_c2. Para reducir la cantidad de filas retornadas, agrego una columna más al índice, la que más me ayude a filtrar.

Debido a que la selectividad de la columna c3 es mejor que la de c4, incluiré sólo la columna c3 en el índice idx_c2. Con eso, reduciré la cantidad de filas que requerirán un lookup de más información. Recuerden que estamos tratando de minimizar el costo del LookUp. Si se quiere suprimir totalmente, se deberán agregar todas las columnas necesarias al índice, solución que deberá dejarse sólo para casos ultra-extremos.

Veamos el plan de ejecución de texto de la misma consulta, pero con el índice idx_c2 incluyendo a la columna c3 además de la c2 que ya tenía.

Table 't2'. Scan count 1, logical reads 3332, physical reads 0, ...
Table 't1'. Scan count 1, logical reads 6, physical reads 0, ...

Rows    Executes  StmtText
-------------------------------------------------------------------------------------------
561     1         |--Merge Join(Inner Join, MERGE:([test].[dbo].[t1].[c1])=([test].[dbo].[t
1001    1               |--Clustered Index Seek(OBJECT:([test].[dbo].[t1].[PK_t1]), SEEK:([  
561     1               |--Filter(WHERE:([test].[dbo].[t2].[c4] = (1)))
1075    1                    |--Nested Loops(Inner Join, OUTER REFERENCES:([test].[dbo].[t2
1075    1                         |--Index Seek(OBJECT:([test].[dbo].[t2].[idx_c2]), SEEK:(
1075    1075                      |--Clustered Index Seek(OBJE...]) LOOKUP ORDERED FORWARD)

Ahora sólo ejecutó 1.075 veces el LookUp. No nos hemos deshecho de él, pero al menos hemos reducido su impacto en el costo de la consulta.

Las lecturas lógicas fueron reducidas desde más de 30.000 a sólo 3.332. Una excelente optimización.

El nuevo costo del operador LookUp es 3,58, como se puede observar a la derecha en el Tooltip. El costo antes de modificar el índice era de 22,06. Otra excelente reducción en el costo.

Conclusión

Hemos visto como minimizar el impacto de la operación LookUp en SQL Server. No vimos como eliminarlo ya que para lograr eso, el camino es directo y simple. A veces no es necesario eliminarlo para mejorar drásticamente el rendimiento de una consulta.

Hasta la próxima, desde Santiago de Chile
Patrick.

Charla de optimización de consultas de SQL

pmackay — Wed, 01 Aug 2007 23:03:00 GMT

Aunque no ha faltado trabajo, las últimas semanas las pasé preparando material para una charla de optimización de consultas en SQL Server que dimos hace algunos días.

Ya ha pasado casi una semana desde que dimos la charla, a la cual asistieron, si mal no recuerdo, 139 personas. Todo salió casi perfecto. Nos faltó tiempo para hacer las demos, aunque los asistentes nos aguantaron estoicamente desde las 6:35 pm hasta las 10:15 pm, 3 horas y 40 minutos. Impresionante.

Algo muy gratificador, y que no siempre ocurre lamentablemente, es poder lograr buena interacción con los asistentes. Usualmente no preguntan mucho, pero en esta oportunidad, estimo que se deben haber realizado 30 o más preguntas y contra preguntas. Así da gusto!!.

La imagen que usamos como ícono de la charla causó risas y simpatía entre nuestros amigos más cercanos.

Los principales temas abordados fueron:

Definición de plan de ejecución, como se construye, que elementos influyen en éste,
Detección de problemas en planes de ejecución
Evaluación de costos, lecturas lógicas
Teoría de índices, relaciones entre índice agrupados y no agrupados
Buenas prácticas, selectividad, estadísticas, fill factor, entre otras cosas.

Aquí van algunas fotos de la preparación de la charla, el evento propiamente tal y la celebración al final. No incluí fotos con asistentes porque uno nunca sabe si quieren o no aparecer. Para ver las fotos más grades, pincha en éstas.

Si te interesa ver el contenido de la charla, ésta está publicada en Cafeina, precisamente éste link.

Estamos viendo de realizar una continuación de la charla, sólo para los registrados de ésta, con el fin de poder terminar las demos y resolver más dudas.

desde Puyehue, al sur de Chile

Patrick

PD: Esta es la vista desde mi habitación acá en el sur de Chile

Entre las excepciones y la flojera de los desarrolladores

pmackay — Fri, 20 Jul 2007 04:07:00 GMT

Una de las recomendaciones importantes en el desarrollo de código es la "no utilización de excepciones para evitar realizar validaciones."

¿A qué me refiero?

A usar try/catch para no tener que escribir código que valide algo. Total, si se cae, en el catch retorno que es falso, si no se cayó, entonces retorno verdadero. Así no es necesario codificar rutinas especiales.

Vamos al caso

Como ya es costumbre en mi trabajo, y de las buenas costumbres, las pruebas de carga muestran la peor parte de las aplicaciones, y esta no fue la excepción, aunque el culpable era código de un componente de terceros.

Pruebas de carga

Treinta minutos de ejecución de un script grabado con ACT, 50 usuarios concurrentes, 30 minutos. No vamos a dar todos los detalles, pero el uso de la CPU estaba "fluctuante", y tenía unas subidas a 100% por varios segundos.

El siguiente es el grafico de performance monitor. Como hay más de 30 minutos, los segundos que la aplicación pasaba al 100% solo se ven como picos, pero en algunos casos llegaba a casi 40 segundos.

Te podrá haber llamado la atención que el uso de la CPU está muy extraño, como que no es fluido, considerando que una prueba de carga debiera mantenerla ocupada constantemente. No tengo la explicación ahora, pero al final veremos algo diferente.

Mientras revisaba contadores varios, me llamó la atención la cantidad de excepciones que se producían a veces, por lo tanto, agregué el contador de excepciones y voila!!. Problema encontrado.

Asombrosa similitud, ¿no?

A tomar dumps en las excepciones para ver que está ocurriendo. Mmm, mejor que no. Con 184 excepciones por segundo, reventamos el servidor. Mejor aún, utilizo un archivo de configuración para AdPlus, que viene en Debugging Tool For Windows, el cual configuro para obtener información de threads, threadpool, stacks manejados y no manejados y excepciones cuando yo le solicite, que será cuando la CPU esté en 100%.

¿Resultado?

Esta es parte del stack no manejado, de un thread manejado. Como este, habían 10 más, es decir, 11 threads lanzando excepciones, a una asombrosa tasa de 184 por segundo.

22 Id: 3924.46b8 Suspend: 1 Teb: 7ffa5000 Unfrozen
ChildEBP RetAddr Args to Child
06ece448 7c827ad6 7c8063cb ffffffff 7921ace1 ntdll!KiFastSystemCallRet
06ece44c 7c8063cb ffffffff 7921ace1 00000000 ntdll!NtQueryVirtualMemory+0xc
06ece4ac 7c8123b4 7921ace1 00000000 793e8730 ntdll!RtlIsValidHandler+0x82
06ece520 7c834d44 06ecc000 06ece530 00010007 ntdll!RtlDispatchException+0x78
06ece800 77e52db4 06ece810 050d5008 e0434f4d ntdll!RtlRaiseException+0x3d
06ece860 7921af79 e0434f4d 00000001 00000000 kernel32!RaiseException+0x53
06ece8b8 7921aefc 1194c7f0 00000000 06eceb14 mscorwks!RaiseTheException+0xa0
06ece8e0 7921aeb0 1194c7f0 00000000 06eceb24 mscorwks!RealCOMPlusThrow+0x48
06ece8f0 79218cc2 1194c7f0 00000000 0219d0b4 mscorwks!RealCOMPlusThrow+0xd
06eceb24 792b1893 00000018 00000001 00000000 mscorwks!CreateMethodExceptionObject+0x67b
06eceb58 79274773 00000018 79274778 06ecec08 mscorwks!RealCOMPlusThrow+0x35
06eceb68 79338b01 0216137a 000000e7 06eceb90 mscorwks!StringToNumber+0x7e
06ecec08 04266804 06ecec14 0f1604f0 000000e7 mscorwks!COMNumber::ParseDouble+0x32

Esta es parte del stack manejado, del mismo thread.

0x06ece908 0x7c834cf4 [FRAME: GCFrame]
0x06ecec38 0x7c834cf4 [FRAME: ECallMethodFrame] [DEFAULT] R8 System.Number.ParseDouble(String,ValueClass System.Globalization.NumberStyles,Class System.Globalization.NumberFormatInfo)
0x06ecec48 0x79a14e0f [DEFAULT] R8 System.Double.Parse(String,ValueClass System.Globalization.NumberStyles,Class System.IFormatProvider)
0x06ecec84 0x79a0e3cc [DEFAULT] R8 System.Convert.ToDouble(String)
0x06ecec88 0x06a30741 [DEFAULT] [hasThis] ValueClass System.Drawing.StringAlignment C1.Util.Styles.StyleContext.1M(String)
0x06ececc4 0x06a306cd [DEFAULT] [hasThis] ValueClass System.Drawing.StringAlignment C1.Util.Styles.StyleContext.GetGeneralAlignment(Class C1.Util.Styles.Style,String)
0x06ececd8 0x06a30246 [DEFAULT] [hasThis] Void C1.Util.Styles.StyleContext.UpdateStringFormat(Class C1.Util.Styles.Style,String)
0x06ececf8 0x0580f464 [DEFAULT] [hasThis] ValueClass System.Drawing.SizeF C1.Util.Styles.StyleContext.GetContentSize(Class C1.Util.Styles.Style,Class System.Drawing.Graphics,ValueClass System.Drawing.SizeF,String,Class System.Drawing.Image)
0x06eced40 0x06a31182 [DEFAULT] [hasThis] I4 C1.Util.Styles.StyleContext.GetContentWidth(Class C1.Util.Styles.Style,Class System.Drawing.Graphics,I4,String,Class System.Drawing.Image)

La información de la excepción se muestra en la siguiente caja, y es equivalente a la presentada en el stack manejado.

Exception 0f69dff0 in MT 79bacb74: System.FormatException
_message: Input string was not in a correct format.
_stackTrace:
00000000
00000000
79bbb998
79a14eb0 [DEFAULT] R8 System.Double.Parse(String,ValueClass System.Globalization.NumberStyles,Class System.IFormatProvider)
06e8eca0
79bac7b0
79a0e3cb [DEFAULT] R8 System.Convert.ToDouble(String)
06e8ed20
79bbf6b0
06a30740 [DEFAULT] [hasThis] ValueClass System.Drawing.StringAlignment C1.Util.Styles.StyleContext.1M(String)
06e8ed24
0573bf28

¿Qué nos dice Reflector del código en el método 1M?

No voy a entrar a analizar que hace o no el código.

Lo único que puedo vez rápidamente es que el desarrollador que codificó estas líneas tenia ganas de irse rápido a la casa, como muchas veces me pasó a mí .

¿Por qué poner un try/catch en vez de hacer la validación que correspondería hacer?

¿Es tan difícil usar un expresión regular para validar decimales o doubles, algo así como "[-+]?[0-9]*\.?[0-9]+"?

Muchas de los try/catch que son codificados podrían ser reemplazados por validaciones con ifs y elses, pero consume mucho más tiempo aprender cosas nuevas, y seguramente las pruebas en el computador del desarrollador no detectaron este problema .

Como no fue posible corregir el código defectuoso, ya que estaba en un componente de terceros, procedimos a hacer unos ajustes y remover parte de la funcionalidad que invocaba ese método.

Nueva prueba de carga

El resultado obtenido habla por si solo. Consecuentemente, el grafico del uso de CPU ahora muestra un comportamiento más esperado para una prueba de carga. Y la gran cantidad de excepciones se fueron.

Conclusión

Tarde o temprano, los problemas aparecen. Es mejor invertir un par de horas en aprender algo que te podrá servir muchas veces a futuro, y dejar la chapucería para otro tipo de actividades.

Estas conclusiones están medias pobres, pero se debe a que no hay mucho más que decir. Los gráficos hablan por sí solos.

Adicionales

Si te interesa aprender de expresiones regulares, existe un muy buen libro y muchos sitios en internet. Personalmente uso el libro Mastering Regular Expressions.

Otros sitios web interesantes:

Saludos,
Patrick.

¿Por qué no debo compilar en modo debug?, Parte III

pmackay — Thu, 12 Jul 2007 04:38:00 GMT

Como lo mencioné al terminar el segundo post sobre por qué no debo habilitar debug=true en web.config, la tercera entrega vendría relacionada con optimizaciones a nivel de código IL.

Si no leíste los posts anteriores, te recomiendo hacerlos, aunque este no es la continuación de ninguno de los dos. Las direcciones son:

Bueno, veamos ahora las optimizaciones que se realizan, aunque siendo más ajustado a la realidad, el código generado en modo debug está des-optimizado y con potenciales "bugs".

Lo anterior significa que en modo debug, se agregan operaciones a nivel de código de máquina, como también instrucciones de código a nivel de IL con el objetivo de apoyar el debugging y la edición en caliente (edit and continue). Utilicé la palabra bugs entre comillas ya que no son bugs reales, pero en un escenario no adecuado, se comportan como tal.

Cuando se compila en modo release, el código generado es de menor tamaño y mas rápido, es decir, optimizado, como esperaríamos que siempre fuese.

Para mi ejemplo, tomaré un problema causado por un ensamblado (assembly) compilado en modo debug, que es exactamente lo mismo que hace debug=true en un sitio web, salvo que tienen ambientes de impacto diferentes.

Dejaremos para la cuarta y última entrega, el análisis de código de máquina.

Excepción lanzada

La aplicación web, en momentos de mucha carga, empezaba a lanzar excepciones del tipo System.IndexOutOfRangeException, con el texto acorde "Index was outside the bounds of the array," estado del cual no lograba salir hasta un reinicio del proceso.

El siguiente era el stack de ejecución al momento de lanzarse la excepción. Las direcciones de memoria son de un sistema de 64 bits.

# Child-SP RetAddr : Args to Child : Call Site
00 00000000`04c9dc50 00000000`7816c664 : ffffffff`fffffffe 00000000`04c9dd90 00000642`7fc2f008 00000001`7fffa790 : kernel32!PulseEvent+0x60
01 00000000`04c9dd20 00000642`7f4477db : 00000642`7f330000 00000002`00000585 00000000`c089c2d8 00000642`7f4508eb : MSVCR80!CxxThrowException+0xc4
02 00000000`04c9dd90 00000642`7fa0e4b2 : 00000000`04b833e0 00000000`06717520 00000642`7f521a48 00000000`00000003 : mscorwks+0x1177db
03 00000000`04c9ddf0 00000642`782caee2 : 00000001`7fffa790 00000642`781043b8 00000642`802a24c0 00000000`00000000 : mscorwks!PreBindAssembly+0x428b2
04 00000000`04c9df60 00000642`80261e22 : 00000642`7882fe08 00000000`c08982c0 00000001`7fffa790 00000000`c00f0a40 : mscorlib_ni!System.Collections.ArrayList.Add(System.Object)+0x32
05 00000000`04c9dfa0 00000642`80282dc9 : 00000000`c089be48 00000000`c08982c0 00000001`7fffa790 00000000`c00f0a40 : ASSEMBLY.NAMESPACE.CLASE..ctor()+0x82

Por cierto, el nombre del ensamblado y la clase han sido modificados. No se llamaban ASSEMBLY.NAMESPACE.CLASE.

Analicemos el stack de ejecución y la excepción

El constructor de CLASE, en la instrucción de offset 0x82 desde el inicio del método, estaba llamando al método Add de un ArrayList.

A su vez, el método Add, en la instrucción de offset 0x32 desde el inicio del método, se estaba lanzando la excepción.

La excepción es de tipo IndexOutOfRangeException, es decir, se está tratando de referenciar un ítem dentro de un arreglo, el cual no existe.

Código del cliente

Revisando el código en el constructor (.ctor) de la clase CLASE, sorpresivamente no se encontró nada relacionado con ArrayList. La clase CLASE es la clase proxy que se agrega a un proyecto, cuando se agrega la referencia de un servicio web . Con mayor razón, nadie ha tendría por qué agregar código ahí. ¿Entonces?

Reflector al rescate

Volcando los ensamblados desde dentro del dump y revisándolos con reflector, apareció este código:

public CLASE() //Equivalente a .ctor
{
    __ENCList.Add(new WeakReference(this));
    this.Url = MySettings.Default.ASSEMBLY_NAMESPACE_CLASE;
    if (this.IsLocalFileSystemWebService(this.Url))
    {
        this.UseDefaultCredentials = true;
        this.useDefaultCredentialsSetExplicitly = false;
    }
    else
    {
        this.useDefaultCredentialsSetExplicitly = true;
    }
}

¿Y esa línea?... Interesante.

Necesitamos más pistas

Desensamblando Add de ArrayList, se obtiene el código de la siguiente sección, siendo la línea blanca la "responsable" del problema.

public virtual int Add(object value)
{
    if (this._size == this._items.Length)
    {
        this.EnsureCapacity(this._size + 1);
    }
    this._items[this._size] = value;
    this._version++;
    return this._size++;
}

Ok, tenemos la línea responsable del error, que está en el código Add de ArrayList. Al evaluar el escenario posible, el error podía estar o generarse en cualquiera de todos estos puntos:

Error en el código de Add
Error en alguna otra parte del código, como CLASE..CTOR
Algo más

El punto número uno se descarta rápidamente, y el motivo es el siguiente. No es que el código Microsoft este libre de bugs, sino que un error en Add de Arraylist habría sido reportado hace 346.432.194.385.037 años..

Nota aparte: Leí en el libro de Debugging de John Robbins, que si el debugging corresponde a la eliminación de bugs, el escribir código corresponde a la creación de bugs. Esto lo podemos interpretar como no hay código libre de errores.

El método .ctor de CLASE presentaba esa línea de diferencia, la causante de todo el problema.

¿Quién es __ENCList?.. más pistas por favor

Está definido como un ArrayList estático, es miembro de CLASE, e instanciado en el siguiente método:

[DebuggerNonUserCode]
static CLASE() //Equivalente a .cctor (sí, cctor con 2c)
{
__ENCList = new ArrayList();
}

Interesante..un método estático, privado y decorado con un atributo de sospechoso nombre (DebuggerNonUserCode), el cual reconozco que no conocía hasta ahora. Recomiendo su investigación.
http://msdn2.microsoft.com/en-us/library/system.diagnostics.debuggernonusercodeattribute.aspx

Además, y algo muy importante cuando utilizas miembros estáticos, es la protección del acceso sobre éste. Que sean estáticos significa que es compartido por todos los threads del proceso. Entonces, se debe cuidar que cuando se haga escritura sobre una variable estática, se haga garantizando que nadie más (otros threads) pueda accederla mientras se realiza la operación. Esto es similar al uso de transacciones en algún motor de datos.

En este caso, el miembro estático no está protegido, lo que en inglés se conoce como thread-safe. El no cumplir con esto, puede llevarnos a situaciones de race conditions. Más información en http://support.microsoft.com/kb/317723/en-us

Recopilando pistas

Tenemos las siguientes pistas:

Error en código que no es del cliente
Código con error es agregado automáticamente por el compilador
Clase estática con miembro estático que no está protegido
Atributo de nombre sospechoso (debug)

Las pistas anteriores no permiten concluir nada en específico, pero dan indicios y suposiciones de donde estaba el problema y qué se debía revisar.

Efectivamente el proyecto web asociado a esta aplicación estaba compilado en modo debug (debug=true), y tanto la variable __ENCList como la línea en el constructor fueron agregadas por el compilador.

Habiendo realizado el cambio para compilar en modo release, y habiendo recompilado el proyecto, el problema no volvió a presentarse, y por supuesto, ni la variable ni la línea tampoco aparecieron en los ensamblados cargados en memoria.

Código de máquina

La revisión del código de máquina quedará para la cuarta y última entrega referente a esto.

desde Santiago, Chile
Patrick.

¿Microsoft y Van Halen?

pmackay — Fri, 06 Jul 2007 19:20:00 GMT

Siendo un fanático de Van Halen, bueno, no tanto, pero me gusta mucho la música de ellos, en especial de la era Hagar, he estado revisando últimamente el sitio web para saber que ha pasado con la banda.

Además de los tradicionales problemas de drogas y de relación entre seres humanos, la última visita a www.vanhalen.net entregó este peculiar mensaje.

If you have registered for our newsletters in the past, please re-register your information, as Microsoft has deleted our database.

Para los escépticos, pueden visitar el sitio y verlo por sus propios ojos, o ver la siguiente imagen capturada desde este.

Que yo sepa, Microsoft no anda borrando bases de datos, ni menos de un grupo de música. A lo mejor no sé toda la historia.

desde Santiago
Patrick.

/3GB, memoria de kernel y un sábado de locos

pmackay — Sun, 24 Jun 2007 20:02:00 GMT

Si no considero las 3 horas que dormí del viernes al sábado, podría decir que llevo casi 48 horas despierto, o que llevaba hasta hoy en la mañana ya que pude dormir 5 horas más de 6 a 11 am (hoy es domingo en la tarde). ¿Cómo tanto?. La primera trasnochada fue por una fiesta de la oficina. La segunda, por un visita fugaz a un cliente en apuros. Mi día sábado fue extenuante y estresante para mi familia, cumpleaños, visitas, compra de pasajes, arreglo de taxis, reservas hoteleras, información adicional, ajustar otros viajes, una locura.

Menos detalles aburridos y vamos al caso

El escenario era similar al descrito a continuación:

Aplicaciones COM+ configuradas por defecto, salvo que algunas de ellas estaban configuradas con diferentes identidades (usuario que será utilizado para ejecutar la aplicación Com+). Las opciones disponibles para identidad son Interactive, Local Service, Network Service o uno específico.
Después de un par de días funcionando, cualquier aplicación COM+ que no estuviese funcionando y era requerida, fallaría al levantarse
Si la aplicación no había sido detenida durante todo el período de tiempo, seguiría funcionando sin problemas, aún cuando otras aplicaciones no pudiesen levantarse.
Si esta aplicación dejaba de ser requerida por más de 3 minutos (valor por defecto) y era bajada, un nuevo requerimiento trataría de levantarla y fallaría.

Claramente no estábamos en presencia de algún problema de código ya que en ese caso, habría fallado siempre. Y más aún, nadie había hecho ningún cambio en los componentes en bastante tiempo.

Investigación del problema

Como en cualquier actividad de resolución de problemas, lo PRIMERO que hay que mirar es el event viewer o visor de sucesos (en español).

Dos tipos de eventos llamaban la atención sutilmente. No habían muchos registros de ellos, pero estaban en el momento adecuado, en el lugar adecuado.

Uno de los eventos estaba en el mismo momento cuando empezaban los problemas. El mensaje era el siguiente.

Failed to create a desktop due to desktop heap exhaustion

Adicionalmente, otros tres eventos habían ocurrido uno de estos días, los que terminaron de aclarar la situación. Este evento el 2019:

Event ID 2019: “The server was unable to allocate from the system nonpaged pool because the pool was empty.”

Serie de preguntas y respuestas

Ingeniero, es decir, yo : ¿Configuraron /3GB en boot.ini?
Contraparte: Si
Ingeniero: ¿y configuraron userva?
Contraparte: No
Ingeniero: mmm...interesante
...
Ingeniero: ¿Cómo andan las PTEs?
Ingeniero: perfmon -> Memory -> Free System Page Table Entries (PTEs) --> cercano a 2.000 ... ouch

Conclusión

El Kernel se quedó sin memoria.

¿Ahh?...bajémoslo a la tierra.

En una arquitectura de 32 bits, la memoria virtual es un recurso medianamente escaso. No vamos a hablar de la cantidad memoria física del servidor. Si bien, mientras más memoria mejor, el problema a describir ahora no depende totalmente de la cantidad de memoria del servidor, ya que o bien tengas 2 o 20 GB, se presentará igual.

Con 32 bits, la memoria virtual, que tampoco tiene que ver con la memoria paginada en disco, está restringida a 4GB por aplicación. El valor 4GB se obtiene al elevar 2 a 32, o 2^32.

De esos 4 GB virtuales, 2 GB son usados por un proceso y los otros 2 por el kernel. Cada aplicación tendrá sus 2 GB virtuales y compartirán los 2 GB de kernel. Debido a esto último, algunos de ustedes recordarán haber visto en Task manager que un proceso nunca pasa de 1,7 o 1,8 GB. Bueno, la explicación es esa. Una aplicación no puede usar más de 2 GB de memoria virtual.

Existe un switch para que sí lo haga, pero con su consecuencia. Este switch se configura en el archivo boot.ini, y corresponde a la opción /3GB.

El impacto de la aplicación de éste es que del espacio virtual de 4 GB, 1 GB pasa de memoria de kernel a memoria de proceso de usuario. Entonces ahora un proceso de usuario puede llegar a usar 3 GB y el kernel queda drásticamente reducido a 1 GB.

SQL Server, Exchange, COM+ y los Application pool de IIS son algunos de los procesos que tomarán ventaja de este cambio y podrán llegar a 2,7 u 2,8 GB de memoria usada, lo que representa un incremento del 50%, y que tiende a ayudar bastante en algunos casos, pero en otros, produce problemas si no se usa adecuadamente (como éste).

¿El problema?

El kernel necesita memoria para poder funcionar, y 1 GB virtual no es suficiente en algunos casos. En el kernel se cargan drivers, el manejador de memoria, de procesos, controladores gráficos, el HAL, manejo de plug & play y otras tareas.

Además, el kernel maneja dos pool de memoria, uno llamado paginable y el otros no paginable. En ingles, paged pool y nonpaged pool respectivamente. ¿Recuerdan el evento 2019? Vuelvan a leer la descripción.

Al aplicar el switch /3GB, el tamaño de estos pools se reduce a la mitad, pudiendo entonces en determinados casos agotarse y poner en riesgo el servidor. Si el kernel no es capaz de obtener memoria de estos pools, varios problemas pueden ocurrir, a saber:

Problemas de interfaz grafica, en donde ésta no responde adecuadamente
Problemas de funcionamiento de algunos procesos, para nuestro caso, las aplicaciones COM+ no levantan.
Falla en procesar requerimientos vía red

Al aplicar /3GB se reduce también la cantidad de PTEs disponibles, lo que generará problemas con los requerimientos de IO, entre otros.

Identidades de aplicaciones

Complementando lo anterior, si recuerdan, en un inicio hablamos de las identidades de las aplicaciones COM+.

Este tópico no lo comprendo a cabalidad, pero puedo decir (con temor a equivocarme) que cada aplicación que es iniciada con un usuario diferente, requerirá que el sistema operativo cargue ciertos componentes para el usuario (desktop). Estos componentes incluyen:

Menús del sistema
Ventanas
Otra información.

Entonces, si tengo aplicaciones COM+ configuradas con X usuarios, podría llegar a cargar X desktops. ¿De donde se obtiene la memoria para cargar estos desktops? De la memoria del kernel.

Como sé que la información que acabo de entregar del tópico de Desktops es bastante limitada, prefiero incluir un link donde esta MUCHO mejor descrita. Aunque está en inglés, no está difícil. El link es http://blogs.msdn.com/ntdebugging/archive/2007/01/04/desktop-heap-overview.aspx.

Solución

Si tu aplicación no hará uso de 3GB, no incluyas la opción. No será necesaria.

Si tienes alguno de los servicios que mencioné antes y necesitas usarlo, deberás entonces usar además la opción userva en el archivo boot.ini.

Userva se utiliza para "mover" un poco de memoria de proceso de usuario a kernel. Realmente no mueve nada, pero el efecto final es que en vez de tener 3GB de usuario y 1GB de kernel, puedes configurar 2,7 GB y 1,3GB respectivamente, lo que ayudará a mitigar el problema, y en la gran mayoría de los casos, desaparecerá totalmente.

El KB referenciado al final muestra como configurarlo. Si bien dice que se deberá probar entre 2900 y 3030, si es necesario para tu sistema, podrás llegar a un valor menor. Mayores valores no tienen sentido.

Si estas usando SQL Server, utiliza mejor AWE por sobre 3GB. No expondrás el kernel a estos problemas.

Adicionalmente, estos links te podrán proveer mas información:

http://technet.microsoft.com/en-us/library/7a44b064-8872-4edf-aac7-36b2a17f662a.aspx
http://support.microsoft.com/kb/316739

Este otro está curioso: http://xentelworker.blogspot.com/2005/10/i-open-100-explorer-windows-and-my.html

Saludos,
Patrick.