OVH, empresa francesa de alojamiento y hospedaje web, se ha ganado una respetable y considerable fama por el buen servicio que ofrece a sus clientes a unos precios razonables y competitivos.
Tengo varios portales alojados en servidores dedicados de esta empresa, realizados con Php y MySQL y nunca he tenido ningún problema serio, que evidentemente no haya sido causado por mi culpa.
Ahora, estamos plenamente inmersos en un nuevo proyecto para desarrollar un portal con Django, utilizando PostgreSQL como sistema de gestión de base de datos, ya que nos han aconsejado que es mucho mejor que MySQL cuando el volumen de información que hay que manejar es demasiado grande.
El proyecto se encuentra en una fase inicial, pero bastante avanzada. El caso es que no hemos dejado de ver errores internos de tipo 500, provocados por algún tipo de condición inesperada. Comprobando los ficheros de log del sistema todo apuntaba a un fallo de hardware.
Se abre un ticket a través del Manager que OVH ofrece para gestión de incidencias y muy amablemente nos invitan a que lo hagamos nosotros. Bueno, pues lo hacemos nosotros. Todo OK.
El caso es que el servidor sigue dando problemas y PostgreSQL sigue dando errores de lectura para muchas de las tuplas de la aplicación, lo que provoca que gran cantidad de las páginas no carguen. Repasando los logs de la base de datos, nos encontramos con cientos de entradas del tipo Dec 7 07:24:45 nsXXXXXX kernel: postgres[22481]: segfault at 7fda5e1d5000 ip 00007fda604553c3 sp 00007fffe41faf28 error 4 in libc-2.9.so [7fda603d1000+168000]
Buscamos el error en la base de conocimiento de PostgreSQL, asociándolo a un ‘Internal Error: Compressed data is corrupt’ y obtenemos como respuesta que el fallo se debe a problemas en el disco o a cierres inesperados de un proceso, algo incoherente con los resultados obtenidos en la prueba de hardware.
Procedemos de nuevo a la comunicación vía ticket. Respuesta desde OVH: “El soporte de incidencias nos confirma que no hay ningún fallo de hardware en el servidor. Nos indican que los fallos son debidos a un fallo del sistema de ficheros o de la tabla de partición, pero físicamente el disco no tiene fallos. El fallo es de software. Puede realizar un chequeo de las particiones y reparar la tabla de archivos.”
La solución temporal ante este problema, hacemos un backup total de la aplicación y base de datos y reinstalamos el SO para ver si se soluciona. Despues de dos días recuperando datos y con el miedo en el cuerpo metido, procedemos a la re-instalacion del sistema operativo, en nuestro caso: Debian 5.0 stable, versión 5.0 Lenny de 64bits, kernel 2.6.31.5-grs(OVH).
Se restaura la aplicación, se restaura el sistema de gestión de base de datos, con PostgreSQL versión 8.3.8 y persisten los problemas del tipo Dec 7 07:24:45 nsXXXXXX kernel: postgres[22481]: segfault at 7fda5e1d5000 ip 00007fda604553c3 sp 00007fffe41faf28 error 4 in libc-2.9.so [7fda603d1000+168000] . Buscamos la versión de PostgreSQL 8.3.9, una versión más estable pero nada, persisten los errores del tipo Dec 7 07:24:45 nsXXXXXX kernel: postgres[22481]: segfault at 7fda5e1d5000 ip 00007fda604553c3 sp 00007fffe41faf28 error 4 in libc-2.9.so [7fda603d1000+168000] . En un intento desesperado, instalamos la versión de PostgreSQL 8.4.2 y adivina adivinanza: Dec 7 07:24:45 nsXXXXXX kernel: postgres[22481]: segfault at 7fda5e1d5000 ip 00007fda604553c3 sp 00007fffe41faf28 error 4 in libc-2.9.so [7fda603d1000+168000]
Vuelta a investigar al final damos con esta web: Imatio Cratio donde nos cuentan la historia de un par de chavales que intentaban hacer su aplicación web y se encontraron en un “fregao” más o menos como el nuestro y en el que en definitiva nos vienen a decir que el origen del problema viene desde la empresa de hosting.
OVH proporciona la variante grsec del kernel en sus distribuciones de sistemas operativos Linux, variante que parece no ser muy buena amiga de PostgreSQL y no los problemas de hardware o software comentados anteriormente. La solución a este problema: utilizar una versión del sistema operativo que no tenga un kernel con una versión grsec.
La moraleja de la historia es que si necesitas utilizar PostgreSQL para tu aplicación web, buscate una distribución de un sistema operativo que no tenga la variante grs del núcleo.
Espero que sirva de ayuda para otras personas que se hayan encontrado con este problema, para evitar en la medida de lo posible que se tengan que pegar días y días tratando de solucionarlo a través de caminos equivocados.
jejej anda que no, o que te despiertes a las 4 de la mñn con 500 emails de errores y creas que la has cagado al programar algo… Sinceramente yo me estaba volviendo loca la semana pasada con el tema pq no sabia que pasaba. Menos mal que se encontro!!!