Archive for the 'Sistemas' Category

Introducción a Moxi – Memcached Proxy

No tiene desperdicio…

¿Os ha gustado? Probadlo.

Anuncios

BlackBerry Enterprise Server en entornos Open Source

El crecimiento de una empresa va de la mano de la necesidad de compartir documentos, disponer de un sistema de autenticación centralizado, y lo muchas veces olvidado, el correo móvil. Empresas como Vodafone ofrecen servicios BIS (Blackberry Internet Service) que ofrecen navegación por internet y servicios sencillos de sincronización de correo, pero ¿Qué ocurre cuando necesitas aplicar políticas de IT a los smartphones o borrar completamente un dispositivo en remoto porque ha sido extraviado? Ahí no hay mucho que hacer, excepto rezar para que tu empleado haya tenido dos dedos de frente y tenga la BlackBerry cifrada.

La utilización de BlackBerry Enterprise Server (de ahora en adelante BES) siempre fue un problema en plataformas que no fuesen Exchange, Lotus Domino o Novell Groupwise, como por ejemplo soluciones open source como Courier, Cyrus, Postfix, etc. Zimbra tiene un conector para BES, pero supone la migración del sistema de correo a otra plataforma. En los entornos Open Source sobre plataformas *NIX es donde el producto ATLAS de la empresa GMV soluciona el problema, actuando como intermediario entre el BES y el servidor IMAP/SMTP. Como no, Vodafone ya parece dar soporte a esta solución.

Sin duda, una buena noticia de la que acabo de enterarme buscando por internet. ¿Alguien ha trabajado con Vodafone en lo que BES/ATLAS respecta? De todos modos, siempre nos quedará Exchange y Windows Mobile, ¿Verdad?

Suhosin causante de una penalización de rendimiento en PHP5

Hace unos meses os hablaba de FatMM, un parche para el core de PHP5 diseñado por Brian Shire, ingeniero de Facebook durante más de cuatro años. Dado que teníamos pensado actualizar la versión de PHP de nuestros frontales, me propuse adaptar el parche para la nueva versión, pero no me fue tan bien a la hora de intentar adaptarlo para PHP 5.3.0, por lo que me puse en contacto con Brian que amablemente me mandó un parche adaptado para la nueva versión. Aquí fue donde comenzamos a discutir acerca del rendimiento extra que obteníamos con el parche, ya que él no parecía muy seguro de que se ganase un de un 4% a un 10% de uso de CPU, así como tampoco había tenido tiempo para hacer sus propias pruebas en un escenario limpio (mismo kernel, todos corriendo la misma distribución por el tema de las versiones de las bibliotecas, misma versión de PHP, misma CPU y memoria, mismo peso en el balanceador, etc).

Me hice con cuatro frontales y los preparé con la siguiente configuración:

Servidor 1: FatMM habilitado con 12MB de reserva y Suhosin habilitado en tiempo de compilación.
Servidor 2: FatMM habilitado con 0 MB de reserva y Suhosin habilitado en tiempo de compilación.
Servidor 3: FatMM habilitado con 12 MB de reserva y Suhosin deshabilitado en tiempo de compilación.
Servidor 4: FatMM habilitado con 0 MB de reserva y Suhosin deshabilitado en tiempo de compilación.

El propósito del test era descubrir si era FatMM el que arañaba uso de CPU, o Suhosin el que añadía la penalización de rendimiento. Los resultados fueron:

Servidor 3 y Servidor 4 han tenido el mismo uso de CPU en hora pico. Servidor 1 tuvo mejor rendimiento que Servidor 2 (la diferencia se veía reflejada solamente en el uso de system cpu), pero bastante peor que Servidor 3 y Servidor 4. En resumen, el parche de Suhosin para PHP estaba añadiendo unas penalizaciones de rendimiento bastante apreciables al core de PHP, y la ganancia de CPU que experimentamos gracias al parche de FatMM se debía a que este parche desactiva las protecciones de Suhosin sobre los malloc() que realiza.

Al saber esto y analizar el parche de Suhosin en profundidad (muchas distribuciones lo añaden por defecto) nos dimos cuenta de que realmente, el parche de Suhosin para el core de PHP (que no la extensión para PHP) no nos aporta nada interesante y nos penaliza el rendimiento en los frontales.

How to get the most bang for the buck (II)

La semana pasada hablábamos de aceleradores de PHP, algo que nos permitiría servir más peticiones por segundo con nuestros servidores web. Hoy hablaré de un parche llamado FatMM que aplicaremos a nuestras fuentes de PHP y que nos permitirá arañarle un poco de CPU a nuestros frontales.

Este parche cambia el comportamiento del gestor de memoria de PHP a la hora de reservar memoria, que en vez de reservar/liberar memoria al vuelo, reserva una determinada memoria a la hora de crear el hijo de PHP y aumenta esta cantidad de memoria si lo necesita. Al final esto permite ahorrar ciclos de CPU gracias a que ahora no tiene que hacer miles de alloc()s, dejando la CPU libre para hacer algo útil. Este ahorro de CPU se traduce en un mayor uso de memoria. Este parche es útil si sirves una página en PHP compleja, y no si sirves contenido estático o sencillos scripts en PHP. Este parche no nos ofrecerá tanto ahorro como APC, pero todo lo que sea arañar uso de CPU es bienvenido, ¿no?

Por defecto el tamaño de memoria reservado es de 64MB, que quizá sea un poco elevado. En la web del autor disponemos de un parche que modifica las fuentes de Apache para poder configurar el servidor web con la constante ZEND_FATMM al valor que deseemos. Lighttpd permite hacer esto a través de la opción bin-environment. ¿Cuál es el valor adecuado para nuestro servidor web? Te toca probar, y ver gráficas de CPU de tus frontales, pero hay que tener en cuenta que la memoria reservada, al contrario de la de APC, es independiente para cada hijo de PHP, por lo que si tienes reservado un segmento de memoria de 50MB y tienes 100 hijos de PHP, necesitarás 5GB de memoria fijos. Hay que añadir a esto la memoria reservada por APC, y la memoria máxima de cada proceso de PHP multiplicado por su número de hijos, teniendo en cuenta que quizá nos podamos permitir el lujo de hacer un poco de sobresuscripción de la memoria del sistema, basándonos en que es bastante improbable que tengas todos los hijos utilizados al mismo tiempo, consumiendo el máximo de memoria permitida a cada hijo de PHP, con el añadido de la memoria reservada por FatMM y APC.

Al fin y al cabo, es echar cuentas. Espero que os sea útil.

How to get the most bang for the buck

¿Cómo acelerar la ejecución de PHP? ¿Cómo ser capaz de servir más páginas por segundo? Este es uno de los retos a los que se enfrenta continuamente un administrador de sistemas en un entorno web con páginas dinámicas. Intentamos exprimir al máximo la infraestructura actual para no tener que desembolsar más dinero comprando nuevos servidores o utilizar más espacio en el CPD.

Desde hace años se vienen utilizando sistemas de caché en servidores web para ahorrar ciclos de CPU en la ejecución de PHP. Estos sistemas de caché funcionan precompilando el código y manteniéndolo pre-compilado en memoria, teniendo que compilar de nuevo el fichero PHP solamente si este cambia, algo que se averigua utilizando llamadas stat(), o bajo demanda, invalidando el objeto manualmente. El utilizar un acelerador de PHP puede hacer que tu servidor web sirva entre dos y cuatro veces más peticiones que sin él. Hay aceleradores de PHP para todos los gustos, cada uno con sus pros y sus contras. No obstante, no todos cubren las mismas necesidades, además de unos estar más maduros que otros. Yo personalmente, por la fase de desarrollo en la que se encuentra, prefiero APC, que además será incluido en el core de PHP6, lo que lo convertirá en el sistema de caché oficial para este lenguaje. Por otro lado, APC permite almacenar información en su memoria compartida, no solamente cachear los ficheros, por lo que si tienes determinada información que no cambia nunca y debe estar cacheada, es un buen sistema, además de fiable.

Lo bonito de APC es que lo instalas y empiezas a ver resultados, ya que seguramente el módulo esté habilitado por defecto, pero aún así tendrás que tunearlo un poco para sacarle toda la chicha que te puede ofrecer. No voy a entrar en esos detalles, pero la principal opción de configuración de PHP es la cantidad de memoria compartida donde almacenará los ficheros precompilados.

apc.shm_size = 32

Esta memoria es la que reserva el padre de PHP, no sus hijos, por lo que quizá te interese funcionar con una configuración compuesta por menos padres y más hijos para minimizar el uso de memoria en el servidor. Cuando la memoria reservada de APC comienza a alcanzar el 95% el segmento de memoria mostrará fragmentación, y dado que estamos alcanzando el límite de la memoria reservada podemos comenzar a tener errores 500 tras actualizar el código del servidor web, o en periodos de actividad intensa del sitio, por ejemplo. El paquete ofrece un fichero llamado apc.php que nos ofrece información avanzada del estado de APC. Es imprescindible echarle un vistazo para tener una visión general del estado de APC y no estar absolutamente ciego.

Errores 500 en servidores corriendo PHP+APC

Esta es vieja, pero si tu tráfico aumenta cada día más, quizá tengas este problema tarde o temprano, siempre y cuando estés usando PHP5 con la extensión APC 1.0.18. Si es así, vuestros servidores web mostrarán errores 500, y el culpable de todo esto es un bug grave de File Descriptors Leakage en esa versión, lo que hace que el servidor corriendo PHP como FastCGI no cierre los descriptores de fichero correctamente una vez abiertos. Podéis ver el número de descriptores abiertos por un proceso utilizando la siguiente orden:

ls -la /proc/8549/fd

En la versión 1.0.19 se soluciona el problema.

Parámetro open_files_limit en MySQL

Hace unos días me encontré con una base de datos de pruebas que mostraba un curioso error mientras hacía una pequeña copia de una base de datos con mysqldump. El error en cuestión era:

mysqldump: Got error: 1017: Can’t open file: ‘*.frm’ (errno: 24) when using LOCK TABLE.

Eso ocurre debido a los valores por defecto de configuración de MySQL establecen la opción open_files_limit a 1024, y cuando tienes múltiples bases de datos con muchas tablas, además de las tablas temporales que crea el motor de base de datos, no es suficiente. Yo, para evitar caer en límites absurdos establezco este parámetro a 50000. Tras cambiarlo debemos reiniciar la base de datos para que este cambio surja efecto.


Las opiniones reflejadas en este blog son personales o ni siquiera son opiniones, y bajo ningún concepto representan las estrategias, opiniones o posturas de mi empresa actual, ni de ninguna en las que he trabajado, así como tampoco de ninguno de los clientes o proveedores de todas ellas.
La información se proporciona como está, sin garantías de ninguna clase, y no otorga ningún derecho. Los comentarios pertenecen a sus autores y bajo ningún concepto el autor del blog se hará responsable de los mismos.

Categorías

Archivos