Archive for the 'Software' Category

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.

Anuncios

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.

Windows FTP client, Microsoft IIS 6.0 y el modo pasivo

Esta última semana me ha surgido un problema. Necesitabamos los datos reales de una serie de estaciónes meteorológicas y no había cojones a transferir por FTP los ficheros. Como era de suponer, cuando nosotros conectábamos en modo activo, la conexión del servidor FTP a nuestra red fallaba por las reglas del firewall. En modo pasivo le ocurría algo parecido, pero al revés. El cliente había abierto los puertos 20 y 21 del firewall, pero no tuvo en cuenta que IIS por defecto usa puertos aleatorios para las conexiones en modo pasivo, y que hay que abrirlos en el cortafuegos (Sería buena idea definir antes un rango estático para facilitar la tarea).

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.

SNI – TLS Server Name Indication

Hoy mientras trasteaba con un servidor web me di cuenta de que la versión 2.2.6 de Apache, y quizá desde la 2.2.2 que es cuando aparecieron los primeros parches, tiene un soporte experimental de SNI. Aún recuerdo este post al respecto. Esto, si el navegador lo soporta nos permitirá tener diferentes certificados por cada servidor virtual (léase hostname) en Apache sin necesidad de disponer de diferentes IP como ocurre ahora. Al parecer Opera ya soporta este ¿método? de negociación TLS, y otros navegadores como Internet Explorer o Mozilla lo incluirán en próximas versiones. Es sin duda, un avance, pero siempre tendremos la espina de los navegadores antiguos. Se puede leer algo más por aquí.

http://trac.lighttpd.net/trac/ticket/386
http://blogs.msdn.com/ie/archive/2005/10/22/483795.aspx
https://bugzilla.mozilla.org/show_bug.cgi?id=116169
http://www.ietf.org/rfc/rfc3546.txt
http://journal.paul.querna.org/articles/2005/04/24/tls-server-name-indication/?postid=70

Resumiendo. Muy bonito pero aunque la limitación técnica está en fase de desarrollo, no tenemos control sobre el navegador que utiliza nuestro visitante, y aunque el fabricante publique una actualización la gente pasa de actualizar nada, por lo que doy fé de que si realmente tiene éxito y funciona bien, tradará MUCHO en implementarse a gran escala. Ya sabéis… la puñetera ley de Si funciona no lo toques.

Comparando SELinux con OpenBSD…

Estaba el otro día leyendo los feeds mientras veía los entrenamientos de F1 del gran premio de China y leí un título interesante: SELinux vs. OpenBSD se titulaba el artículo. Coño, a ver que cuentan…

Pues quieren comparar SELinux que es lo que es con OpenBSD que también es lo que es. Los argumentos son de lo mejorcito:

  • Es complejo: Vale, no es fácil, aunque distros como Fedora y RedHat creo que tienen asistentes. ¿Tiene OpenBSD algo tan potente? ¿Hasta dónde llega TrustedBSD? Solo hay que buscar un poco por internet para leer preguntas como Does OpenBSD have something similar to the NSA`s SELinux, RSBAC, PaX stack smashing protection, Grsecurity etc? y leer esta joya de respuesta: OpenBSD has a “secure-by-default” approach with focus on security and code correctness. There`s no need for extra addons like SELinux and grsec kernel patches.
  • Insinuan, o me lo parece a mi, que APPArmor es mejor que SELinux cuando APPArmor tiene al menos que yo conozca, limitaciones, como que no permite controlar sockets, o que se referencia a los ficheros por su ruta y no mediante labels en el sistema de ficheros (Como si de una ACL o atributo extendido se tratase). Aquí una comparación de ambos.

Os dejo un artículo que me gusta mucho ya que explica muy bien como funciona PaX (Parte de la suite GRSecurity para Linux, que aunque no tenga nada que ver con SELinux, es un elemento más en la fortificación de un sistemas Linux) y W^X de OpenBSD.

Vamos, que en mi opinión no es solamente qué se usa, sino cómo se usa y como de implementa, y en mi opinión Linux ofrece más herramientas para fortificar el sistema que un sistema OpenBSD y quien no quiera ver más allá de la calidad del código en mi opinión no está haciendo una buena evaluación de todo el rol. OpenBSD todos sabemos que tiene fallos. Pocos, pero ahí están y sus paquetes tambien tienen fallos, y los paquetes no son parte del core, luego no son auditados, luego la misma cagada que comete el devel de determinada aplicación de lo que sea en Linux, puede cometerlo en el paquete de OpenBSD (Si lo incluye, claro, y si tiene esa misma versión). Y digo yo… de que sirve tener un sistema base con un muy buen código si luego tu aplicación que escupe html o correo es vulnerable? Creo que es ahí donde entra PaX, SELinux, RSBAC, etc intentando que la explotación de la vulnerabilidad no sea tan fácil de llevar a cabo…

Esa es mi opinión. Un saludo.


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