¿Os ha gustado? Probadlo.

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?

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.

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.

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.

ls -la /proc/8549/fd

En la versión 1.0.19 se soluciona el problema.

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.

echo h > /proc/sysrq-trigger; dmesg | tail -n 1
SysRq : HELP : loglevel0-8 reBoot tErm Full kIll saK showMem Nice powerOff showPc show-all-timers(Q) unRaw Sync showTasks Unmount shoW-blocked-tasks

Veamos un ejemplo de cómo reiniciar el servidor:

echo s > /proc/sysrq-trigger; echo b > /proc/sysrq-trigger

Esto sincronizará los sistemas de ficheros montados y reiniciará el servidor. Útil cuando sabes que el estado del servidor es irrecuperable sin un botonazo, y un reboot de toda la vida  no solventa nada.

Un saludo,

Las entradas en concreto son:

hosts: files mdns4 [NOTFOUND=return] dns

Eliminando estas entradas escritas en negrita se soluciona el problema que es, basicamente, la imposibilidad de resolver dominios .local en distribuciones actuales como Ubuntu, quedaría solucionado. Algunos enlaces de interés:

Avahi mDNS/DNS-SD

ZeroConf

Le di unas instrucciones de como configurarlo, que podéis leer aquí y aquí, pero al día siguiente me respondió que preferían no tocar su servidor, que tienen otros clientes que conectan y tenían miedo de probarlo en producción. Les ofrecí una cuenta entonces en nuestro servidor y ¿Qué ocurrió? Que fallaba. Joder, joder, a ver ahora como modelizamos los datos reales de los últimos seis meses. Me pongo a mirar el log y veo errores 425 (No se ha podido establecer la conexión). Claro, están teniendo el mismo problema que nosotros, conectan en activo a nuestro servidor y cuando éste intenta establecer la conexión de datos (Si haces un STAT funciona el listado, pero un LIST, un STOR o un RETR) se mete la ostia contra su firewall.

Fue entonces cuando me acordé de la utilidad que me dió la vida, wput, que soporta transferencias en modo activo y pasivo, TLS, límites de velocidad, resumen de las transferencias, etc. Vamos, una maravilla que basta con descargarla y ejecutarla, sin tocar el registro y lo mejor de todo, que funciona desde línea de comandos para poder automatizar tareas. El perfecto sustituto del cliente FTP de Windows que muchos de nuestros clientes utilizan para transferirnos datos.

Al fin, hemos recibido datos reales y en unos días estarán modelizándose en el HPC Cluster de Holanda.