No podría más que recomendar huir de CentOS/RedHat, son con mucha diferencia las que más problemas me han dado siempre.
Para muestra, un botón, de hace unos días: una web funciona muy bien en un servidor con Gentoo. Se mueve a un servidor como 12 veces más potente, con CentOS... y el rendimiento cae en un 800%. Donde antes se servían 100 peticiones simultáneas ahora con dos ya consume el 100% de CPU. ¿El problema? RedHat metió parches de Perl 5.9 (desarrollo) en la rama 5.8, y uno de ellos simplemente no funcionaba y una función se comía ella solita el 95% de CPU. ¿Solución? Revertir a mano el parche de RedHat, recompilar y voilá, funcionamiento perfecto.
Lo siento, pero no puedo fiarme de una distribución (y derivadas) en la que me van a mezclar código de la rama de desarrollo en las versiones estables sin avisar, por algún oscuro motivo interno, ya que leyendo al tratar de resolver el problema he visto que esto es práctica habitual en RedHat. Irán un paso por delante de otras, pero cuando algo sale mal el desastre es importante, sobre todo porque confías en no encontrarte un error de la rama de desarrollo en la de producción.
no más...
(Puntos:1)( http://sipakal.blogspot.com/ )
El poder de los Datos...
Yo al contrario
(Puntos:1)( http://www.alvaroremesal.net/ | Última bitácora: Viernes, 24 Abril de 2015, 19:48h )
Para muestra, un botón, de hace unos días: una web funciona muy bien en un servidor con Gentoo. Se mueve a un servidor como 12 veces más potente, con CentOS... y el rendimiento cae en un 800%. Donde antes se servían 100 peticiones simultáneas ahora con dos ya consume el 100% de CPU. ¿El problema? RedHat metió parches de Perl 5.9 (desarrollo) en la rama 5.8, y uno de ellos simplemente no funcionaba y una función se comía ella solita el 95% de CPU. ¿Solución? Revertir a mano el parche de RedHat, recompilar y voilá, funcionamiento perfecto.
Lo siento, pero no puedo fiarme de una distribución (y derivadas) en la que me van a mezclar código de la rama de desarrollo en las versiones estables sin avisar, por algún oscuro motivo interno, ya que leyendo al tratar de resolver el problema he visto que esto es práctica habitual en RedHat. Irán un paso por delante de otras, pero cuando algo sale mal el desastre es importante, sobre todo porque confías en no encontrarte un error de la rama de desarrollo en la de producción.
-- Txeke