Hola a todos,
Se acercan mis vacaciones, he estado buscando cosas interesantes que contar, ya dije al principio que la idea de este blog era publicar cosas que yo considero "interesantes" y no os engañéis, en la vida de un programador de gestión (por lo menos en la vida de los que yo conozco...), no hay muchos momentos brillantes al año, la verdad es que el trabajo es muy repetitivo, es una pena!!
En fin, este año, lo que llevo de año, tuve un pequeño problema con un pase a producción. Un día (qué recuerdos...) hacemos el típico pase chorra a producción, nada del otro mundo, un par de pequeños cambios, uno más o menos gordo, pero nada de qué preocuparse, además, se había probado correctamente en pre-producción. El caso, se sube a producción, se prueba, todo correcto y hora y media después, llamada mortal !!! "Antonio, el servidor se ha caído...", sudores fríos recorrían mi cuerpo serrano. Bueno, no pasa nada!!! se reinicia y punto (algunos ya estaban moscas con el pase.... jajajajajaja). Una hora después.... "Antonio, se ha vuelto a caer..." vale, esto no es normal, me dije a mi mismo....como hemos hecho un pase, lo echamos para atrás y reiniciando que es gerundio.... :-((((
En estos casos todo el mundo comienza a hacerse preguntas, en estos casos, muchos, en lugar de buscar soluciones, se encargan de confirmar que el error JAMÁS puede ser por su culpa... jajajajajajaja, pero es lo "normal", yo siempre he dicho que me encanta ver la reacción de la gente en una "cagadita" de pase a producción, ves a los que se quitan el marrón de encima, ves a los que se alegran de que la hayas cagado, ves a los que pierden el culo por enviar mails a todo el mundo de que hay un error y no es suyo, ves a los que parece que el error no tiene nada que ver con ellos, aunque hayan participado activamente en algún cambio del pase y ves a los que sin tener nada que ver, ayudan y a los que tienen que ver con el pase se responsabilizan.... no hay nada como un error gordo en producción, para saber de que tipo de personas estás rodeado (esto es un consejo...).
Como casi siempre, procedimiento estándar, ponemos el .war del pase en el entorno de pre-producción (después de comprobar que producción ya no se caía.... aquí muchos ya respiraron más tranquilos al saber que no era su culpa... jajajajajajaja) y comenzamos a hacer las pruebas otra vez, ¿resultado? todo correcto, esto me da mucha rabia!!!!, a mi me gusta, como a todos, que si algo falla, falle en todos los entornos, no hay nada peor que no poder reproducir un problema!!!, a lo que iba, como estaba claro que era "algo" que pasa en producción y que en integración no somos capaces de hacer, ¿qué puede ser? nos preguntamos, hemos modificado cosas de las reservas y cosas de consulta de usuarios, tiene que ser algo de eso, seguro!! nos decíamos a nosotros mismos.
En este caso, y con la tranquilidad de que el pase no era urgente y ya no se estaba reiniciando el servidor, me pregunté ¿qué ha llenado la memoria? Ah sí!!! el error era que se había llenado la memoria!!! ¿podemos verlo? ¿podemos saber qué había antes de llenarse? ¿podemos saber "algo"?.
Bueno, por suerte para mi, cuando se llena la memoria, el servidor web deja un fichero llamado head.hprof (si está correctamente configurado....) con lo que había en la memoria antes de colapsarse, bueno, un inicio!!!, no está mal!!! (a todo esto mis compañeros comenzaban a comentar los cambios y haciendo subidas controladas a producción para ver si alguno de esos cambios era el que provocaba la saturación de la memoria...sin éxito absoluto...el típico ensayo/error), por lo que ya tenía algo qué investigar. Investigué qué era este fichero, porqué se generaba, miles de páginas de Internet que explicaban el problema y muy pocas la solución, todas hacían referencia al famoso Memory Leaks (fugas de memoria...), el error que parecía ocurría en mi servidor, todas hablando de teorías hermosas, rinbombantes y elegantes de porqué se producen fugas de memoria (porque se programa mal, básicamente!!!!), pero pocas hablando de como se detectan esas fugas de memoria. Aún así, en alguna de ellas (una, la más clara que encontré.....), hablaba de que la única forma para solucionar el problema era ver el famoso fichero generado por el servidor antes de fallar y ahí nos daría una idea de qué es lo que había en la memoria antes de fallar.
Lo malo de los ficheros .hprof es que son tan grandes, como la memoria de servidor, en nuestro caso, tuvimos más suerte porque el fichero sólo es de 2GB (sí yo también flipé con la poca memoria que tenemos en producción!!! pero es lo que hay... jajajajaja), pero bueno, como contaba antes, en una de esas páginas, se hablaba que con el programa Eclipse Memory Analyzer era posible ver el contenido de ese fichero de forma gráfica, navegar entre los datos y hacerse una idea clara sobre el posible error. A todo esto, íbamos de fracaso en fracaso comentando los cambios y subiendo a producción.......
Aquí os dejo (y así me quedé yo el viernes antes de irme a casa...) angustiado por un error que no aparecía y no éramos capaces de reproducir, con un pase que no pude hacer a producción y que comenzó el jueves, con pequeños cambios comentados en el código de lo añadido al pase que seguían produciendo fugas de memoria y con la esperanza de encontrar un manual de como utilizar e interpretar los resultados del EMA el fin de semana para intentar arreglar el problema el lunes. No se a vosotros, pero a mi esta cosas consiguen "picarme", son estas cosas que hacen que llegues a casa y continúes buscando información y ejemplos por internet, y creo que el día que no sea así, debería dejar de programar (un día os contaré mi visión sobre capacidad y actitud en otra entrada....).
El próximo día continuo!!!! chao!!!
No hay comentarios:
Publicar un comentario