Este es un post técnico que complementa al de cómo implementé el tema de NginX + PHP en FastCGI.

Desde siempre, dados varios bugs conocidos de php en cgi que, según la versión, hacían que los sockets fueran más o menos estables tenía un proceso en el cron del sistema que me reiniciaba el php (los sockets realmente) cada día a las 6:15 de la mañana.

A veces, cada X semanas, el php se quedaba colgado y lo reiniciábamos manualmente. NOTA: no es que el php se quedaba colgado, el tema radica en que el socket de escucha se quedaba tonto sin responder, los procesos de php seguían ejecutándose esperando cargas y peticiones (en estado suspendido). La solución al reiniciar, era que matando los procesos y rearrancando esa parte, el socket se creaba de nuevo y volvía a la normalidad.

Esto no se trata en casi ninguna web, exceptuando una: En el blog de Taragana.

Tras varios meses así, decidí implementar una mejor solución. Encontré una versión mejorada para Ubuntu (aunque yo uso Debian) de un script de arranque usando demonios. Tras esto, mejoraba 2 cosas: era más consistente el arranque (al poderlo poner en el arranque del sistema sin problemas) y se cargaba la configuración de php con más megas de RAM asignados (de la otra manera lo que pasaba era que se arrancaba el php en fcgi con valores por defecto (aunque le pasara por parámetro el fichero php.ini).

Estos scripts básicamente son dos: /etc/default/php-fastcgi (fichero de configuración) y el script de arranque.

Este cambio lo realicé a principios de enero y durante 2 semanas no dió ningún problema, tuve que comentar la linea de reinicio del cron porque no era necesario.

Pero tras eso, por alguna actualización o algo, la cosa fallaba como una escopeta de feria. Volví a poner el reinicio cada 2 días, pero ni eso… lo volví a poner a un día. Pero no bastaba…

La solución por probar era compilar el php-fm, pero se me antojaba demasiado complicado para dejar el sistema tal como lo tengo ahora, así que decidí investigar.

Primero pensé en ver si había alguna otra implementación de sockets que recibiera peticiones y pudiera ejecutar lo recibido usando el cliente normal de php de bash. Miré si había alguna manera de crear sockets desde 0 con php para este fin, pero no había nada sin tener que sumirme en decenas de varios de documentos de programación en C sin tener mucho tiempo.

Tras buscar, llegué hasta un blog que hablaba del tema. El auto se había programado un script en python que, básicamente, escaneaba por errores en el log del NginX cada 2 segundos sin impacto en el sistema. El que aquí os pongo simplemente tiene comentadas las lineas para enviar correo, dado que pasaba mal algunos parámetros al sendmail y se colgaba.

Básicamente, lo que hace es:

• Se ejecuta y se ‘demoniza’, así que se queda en el sistema.
• Escanea el /var/log/nginx/error.log cada 2 segundos, usando algo como tail -f.
• Si se encuentra en el log las cadenas “104: Connection reset by peer” o “111: Connection refused”,
  • Ejecuta un killall -9 php5-cgi (el binario se puede configurar)
  • Ejecuta el script de arranque /etc/init.d/php-fastcgi start

Al usar el tail -f, se usa muy poca memoria y permite estar tranquilo… como mucho hay un downtime de varios segundos. Luego se arranca como si no hubiera pasado nada.

Para evitar que algo reviente el phpmonitor.py, he creado un script en bash ejecutado cada minuto via cron que simplemente mira si se está ejecutando el monitor. Si se ejecuta, sale; si no, lo ejecuta. La doble seguridad o doble chequeo es necesario.

Cosas a mejorar:

• En el script de python, podríamos usar el propio script de arranque para parar los procesos en lugar de hacer un kill directamente; o usar un simple restart…
• Aplicar una parte de la solución de Taragana: crear pools para cada aplicación, así no siempre se quedaría todo parado. Aunque eso implicaría modificar el script de python para discriminar entre dominios/aplicaciones y no reiniciar lo que no toca

Alguien tuvo acceso a muchos datos referentes al precio de transmitir datos en Internet en los últimos 10 años. Es increible observar la tendencia general del declive del precio, sobretodo en la última década. Y esas tarifas solo hacen referencia a lo que las empresas pagaban, pero no incluye la depreciación general.

En 1998, el precio medio pagado por los distribuidores de contenido para transmitir video a Internet era de 15 céntimos de dólar por megabyte transmitido. Repetimos, por transmisión; eso no incluye el precio del hosting donde tener el archivo etc. Para entonces, las cosas no se medían en GB o TB, dado que nadie transmitía tanto, y la media del video transmitido era a un ancho de banda de 37Kbps. Si avanzamos hasta el presente, tenemos que empresas como Netflix codifican y transmiten contenido a un bitrate 90 veces más grande que en 1998.

Para ponernos definitivamente en el tema, y para que todo el mundo lo entienda, a día de hoy Netflix paga 5 céntimos de dólar para transmitir TODA una peli por Internet. Si Netflix existiera en 1998, y a la misma calidad que hoy, le costaría la friolera de 270 dólares por peli. Por supuesto, en 1998 nadie tenía conexión de 3 Mbps, incluso si solo se codificara los videos a 37Kbps, ello le saldría entre 2′40 y 4′80 dólares por una sola peli. Todo esto os sirve para daros una idea de cuan lejos ha llegado la validad del video en internet, hábitos de consumo y tarifas a grandes rasgos de los últimos 10 años.
Pero incluso con esa bajada de precios tan sorprendente, las compañías siguen haciendo números para conseguir dinero con el tema del video de online.

Texto original aquí.

Hacía tiempo que veía una cosa extraña en la instalación del servidor: se actualizaba todo menos el paquete principal de las webs, el NginX (servidor de alto rendimiento).

Tras buscar un poco, me percaté de este hilo en los foros de Ubuntu que realmente, en ubuntu/debian no se actualizaba dicho paquete desde la versión 0.6.35 (y eso que nosotros usamos testing).

En la web, esa versión ya aparece como legacy (en plan funcionó pero está obsoleta), siendo la versión de desarrollo la 0.8.4 y la estable la 0.7.61

La verdad es que no sé por qué no se ha ido actualizando, pero veo que no es cosa nuestra, pues este programejo ya ha pasado a lighttpd en cuestión de sitios que lo tienen instalado.

Como está en inglés, ahí va la receta para actualizar desde debian/ubuntu con apt:

1. Verificar que no tengais nada referente al nginx en el /etc/apt/preferences
2. Para instalar desde 0, primero instalad la versión que os ofrece vuestra versión, desde los repositorios oficiales
3. Modificad vuestro /etc/apt/sources.list para añadir esto:
   deb http://apt.avuc.nl lenny stable
   deb-src http://apt.avuc.nl lenny stable
4. ‘Upgradeais’
5. Como el que nos provee estos paquetes es una persona diferente, compiló con otras opciones; pero solo hay que hacer:
   ln -s /usr/local/nginx/sbin/nginx /usr/sbin/nginx
6. Reiniciar el nginx con vuestro script de toda la vida ( /etc/init.d/nginx)

Tras esto, ya tenemos nuestro nginx listo en la última versión.

La persona del post del foro se ha ofrecido voluntario a ir compilando las versiones estables y ponerlas en el mismo repositorio.

Actualización: se me había olvidado mencionar que, buscando cosas del nginx, me topé con este convertidor de reglas htaccess a nginx.

]]> http://www.arlay.net/2009/07/03/actualizando-el-nginx/feed/ 1 http://www.arlay.net/2009/03/20/10-maneras-de-hacer-copia-de-tu-mysql-metodo-5/ http://www.arlay.net/2009/03/20/10-maneras-de-hacer-copia-de-tu-mysql-metodo-5/#comments Fri, 20 Mar 2009 07:42:32 +0000 Relay http://www.arlay.net/?p=648 5. Pasar tu base de datos a un fichero XML con PHP

Aunque eso simplemente es una manera burda de hacer la lectura más comprensible, la verdad es que si la base de datos es muy grande, la lectura posterior para integrarla de nuevo en un motor MySQL será más rápida por la estructura de árbol que adopta el fichero XML final.

Podeis leer el código en la web de David Walsh.

Anterior método -

4. Directamente con mysqldump a saco

En los anteriores métodos ya se ha usado mysqldump, una utilidad que viene con el mysql en cualquier sistema. Aparte de combinarlo, dicho mysqldump ofrece opciones variadas que, con varios ejemplos, repasaremos para ver como hacer los backups a tu manera.

De la manera más sencilla, el comando se ejecuta con el siguiente esquema:

mysqldump ---user [nombre de usuario] ---password=[contraseña] [base de datos a copiar] > [fichero de salida]

No creo que haya mucho que explicar al respecto.

Como opción extra, se puede usar el argumento -opt:

mysqldump --opt basededatos > sql.dump

Especificando el argumento --opt, en teoría, estamos haciendo un volcado preparado para ser luego introducido en otro MySQL. Aunque suene raro, la explicación es sencilla: con dicho argumento, el mysqldump crea un volcado má´s sofisticado, incluyendo sentencias como “DROP TABLE IF EXISTS” entre otras. Así, no habrá problema en recuperar una copia del día anterior si ha habido algún destrozo interno o alguna salvajada en el mismo servidor. Además, se meten sentencias de bloqueo, para evitar problemas de concurrencia a la hora de que los datos se vuelquen tanto fuera como dentro de otro MySQL.

Volcando de un servidor a otro ‘on-the-fly’:

mysqldump --host=host1 --opt basededatos | mysql --host=host2 --C nuevabase

Usando las tuberías en unix/linux (pipes), se puede hacer una pequeña virguería como la descrita. Podemos pasar el argumento host (que contendrá la IP o el nombre de la máquina) para, a la vez que volcamos con mysqldump, aceptarlo e integrarlo en otro servidor con el cliente de consola de mysql. Nótese el argumento –opt de la primera parte, y el –C de la segunda, donde se especifica que se compriman los datos que viajen.

El único inconveniente es que la nuevabase debe estar creada en el host2 antes de ejecutar el comando. Ambos servidores deben permitir conexiones desde fuera si se lanza este comando desde otra máquina remota que no sea ni el host1 ni el 2.

La típica:

mysqldump ---user admin --password=password basededatos |  gzip > backup.gz

Esta es la típica opción que se usa en el 90% de los casos que conozco… un volcado, y comprimido usando gzip (se puede usar cualquier compresor de consola).

Como últimos argumentos a comentar, estan el –no-data y el –databases:

mysqldump --no-data --databases mydatabase1 mydatabase2 mydatabase3 > sql.dump

El primero simplemente especifica que no se vuelquen los datos, sino solo la estructura. El segundo, argumenta que le pasaremos varios nombres de diferentes bases de datos para volcar. No hay mucho más que os pueda servir.

Como restaurar lo que se ha volcado:

Esa era la pregunta que os deberíais estar haciendo, si es que no habeis restaurado un mysql nunca.

La solución pasa por invocar el cliente mysql a pelo pasándole como parámetros el nombre de la base de datos y el fichero sql que tengamos:

mysql mybasededatos < sql.dump

Via | SitePoint

Anterior método. – Siguiente método

Básicamente se trata de crear una tarea en el cron para que automatice la creación del backup (solo viable si el servidor de BDD es un linux).

15 2 * * * root mysqldump -u root -pPASSWORD –all-databases | gzip > /mnt/disk2/database_`data ‘ %m-%d-%Y’`.sql.gz

Aquí básicamente definimos el usuario root y su password para realizar una copia completa de todas las bases de datos que esté manejando mysql. Esto se puede reducir si cambiamos el usuario/contraseña y le especificamos la base/tabla a copiar. Lo concatenamos con gzip para que se comprima el sql y se le añade la fecha (pillada del sistema)

En caso de que el servidor no sea un Linux, se podrá crear una tarea programada (si es Windows) para realizar un simple mysqldump:

mysqldump -u root -p wordpress wp_posts > D:\wordpress_posts.sql

Lo anterior sería un ejemplo de volcado de la tabla de posts de un blog.

Via | Backup HowTo

Anterior método - Siguiente método

El método 1: Copiar automáticamente la base de datos a Amazon S3

Mucho usuarios hoy en día usan las capacidades de Amazon S3 para realizar las copias de mysql. Aquí tenemos un pequeño script que, aparte de realizar la copia, se encarga de subirlo a Amazon S3 (en django).

Cosas a cambiar antes de usar dicho script:

1) Hay que poner la libreria de Amazon S3 propia para python en el path del sistema (para que sea visible). Podeis bajar dicha libreria en este link: http://developer.amazonwebservices.com/connect/entry.jspa?externalID=134

2) Hay que mantener el script mysql_to_amazons3.py  en el mismo directorio que settings.py.

3) Definir las siguientes variables en el fichero settings.py

• MYSQL_DUMP_PATH=  “/usr/bin/mysqldump”

mysqldump es el comando con el que se hace la copia (se hace un volcado realmente) de la base de datos.Hay que darle todo el path al ejecutable.

• AWS_ACCESS_KEY_ID = ”

Esto es la clave para acceder a los servicios de Amazon. Esto se da tras darse de alta.

• AWS_SECRET_ACCESS_KEY = ”

La secret key (o password) que también da Amazon para poder acceder.

• BUCKET_NAME = ‘tempstore’

El nombre del contenedor donde guardar el fichero final de copia. Bucket es básicamente un contenedor (al pagar a Amazon S3 por el espacio ocupado, crear contenedores vendría a ser como crear directorios/carpetas).

• ARCHIVE_NAME = ” “

Nombre del fichero final que se va a guardar.

• Hay que cambiar las variables DATABASE_NAME , DATABASE_USER y DATABASE_PASSWORD
  para que contengan los valores de la base de datos a copiar, y el usuario y contraseña para poder hacer dicha copia.

Ejecutando el script:

1. Basta con ejecutar ‘python mysql_to_amazons3.py’ (sin comillas) para que se haga la copia y se suba a la cuenta de Amazon, con el nombre de fichero definido en el ‘contenedor’ designado.
2. El script deja una copia de la base de datos que se ha enviado en el directorio donde se encuentra dicho script.
3. El archivo contiene dos ficheros: _data.sql que contiene los datos, _struct.sql que contiene la estructura básica de la abse de datos. Esto se ha hecho intencionadamente, es una buena práctica.
4. Si se quiere hacer una tarea programada, lo mejor es usar crontab –e con el usuario que quiera lanzarlo para hacer la definicion.

¿Cual es el flujo de trabajo del script?

1.Usa subprocesos. Básicamente, usa la función Popen (pipe open) para ejecutar varios comandos (mysqldump -  -  – ).

2. Se lee la salida de estas tuberias para crear el fichero .tar.gz

3. Usa la API de Amazon S3 para subir el fichero.

Via | Uswaretech

Siguiente método.

Tras no tener que reiniciarlo pese a las actualizaciones semanales que le íbamos haciendo, en estos últimos días se ha colgado el servidor 2 veces en 76 horas.

Tras más de 170 días de uptime, con velocidades decentes y soportando cargas a punta pala sin inmutarse o despeinarse, una actualización con bug del kernel de linux hizo que la máquina se quedara sin conexión.

Una lástima, pues en los últimos 6 meses llevábamos como 5TB transmitidos hacia afuera y 600 GB de tráfico entrante.

El problema parece ser un bug que afecta a las tarjetas de red, no sé si a todas, pero sí a las Realtek que hace que la tarjeta empieze a desconectarse y volver a conectarse… y luego directamente el driver se cuelga, dejando sin red a la maquina en cuestión.

La máquina parece que sigue viva, pero sin conexión. En este caso, solo puedes mandar un ticket al datacenter para que lo reinicien o reiniciarlo tu en remoto si te dan la opción (un panel que te suele dar el dc).

Tras esto, me puse a investigar, y ví esto en el log:

Jan  3 12:34:13 NaRRa kernel: [41979.812779] NETDEV WATCHDOG: eth0:
transmit timed out
Jan  3 12:34:13 NaRRa kernel: [41979.812821] ————[ cut here
]————
Jan  3 12:34:13 NaRRa kernel: [41979.812849] WARNING: at
net/sched/sch_generic.c:222 dev_watchdog+0xa6/0xfb()
Jan  3 12:34:13 NaRRa kernel: [41979.812881] Modules linked in: ipv6
fuse loop snd_pcsp snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm
psmouse snd_timer i2c_
i801 iTCO_wdt snd soundcore serio_raw snd_page_alloc i2c_core
intel_agp evdev ext3 jbd mbcache raid10 ata_generic sg ehci_hcd
ide_pci_generic ide_core uhci_hc
d sr_mod cdrom sd_mod thermal_sys e1000e e1000 raid456 async_xor
async_memcpy async_tx xor raid1 raid0 multipath linear faulty md_mod
dm_zero dm_snapshot dm_r
ound_robin dm_mirror dm_log dm_emc dm_multipath dm_crypt dm_mod
crypto_blkcipher aic7xxx aic79xx scsi_transport_spi aacraid sata_vsc
sata_via sata_uli sata_sx
4 sata_svw sata_sis pata_sis sata_sil24 sata_sil sata_qstor
sata_promise sata_nv sata_mv raid_class ata_piix ahci libata dock
3w_xxxx 3w_9xxx scsi_mod
Jan  3 12:34:13 NaRRa kernel: [41979.813260] Pid: 0, comm: swapper Not
tainted 2.6.26-1-amd64 #1
Jan  3 12:34:13 NaRRa kernel: [41979.813287]
Jan  3 12:34:13 NaRRa kernel: [41979.813287] Call Trace:
Jan  3 12:34:13 NaRRa kernel: [41979.813325]  <IRQ>
[<ffffffff802349b8>] warn_on_slowpath+0×51/0×7a
Jan  3 12:34:13 NaRRa kernel: [41979.813366]  [<ffffffff802461b2>]
autoremove_wake_function+0×9/

Ahora parece que aguanta sin problemas

Rudy afirma que Psystar existe, y que no es ningún engaño. La razón por su aparente desaparición fue la desbordante demanda de ordenadores que tuvieron, que causó que la compañía que administraba sus pagos con tarjeta de crédito cerrara la cuenta por tener que procesar demasiadas terjetas. Además, dicha compañía les forzó a moverse a un sitio más grande para que pudieran producir sus OpenComputer a gran escala.

El presidente de Psystar también ha afirmado que no están escondiéndose de Apple, sino que sencillamente se han visto desbordados por la demanda. De hecho, asegura que muy pronto podrán volver a aceptar pedidos. Desde mi punto de vista personal, de momento no haría ningún movimiento hasta tener confirmaciones más fiables. Recordemos que la legalidad del OpenComputer con Mac OS X Leopard instalado es bastante dudosa.

Como dicen en Applesfera, yo ya dudo de mi anterior post sobre la empresa que iba a dar ordenadores compatibles con Mac OS X Leopard.

El problema, aparte de todo lo que he copiado (que me perdonen los de Applesfera), es que hay una claúsula básica en este sistema operativo que reza: Solo usar en máquinas Apple.

Es decir, solo puedes usarlo en ordenadores fabricados por Apple, nada de montarte tu clónico e instalar.

Soy más partidario de que Apple ponga su software en todos los ordenadores, sacando versiones específicas.

Aunque algunos crean que no ganarían pasta, yo sé más de uno que directamente compraría el sistema operativo.

Los números no engañan: vale que ganas 1000 euros en cada equipo que vendes, que le incluyes el sistema operativo (-120 euros aprox del total). Como vendes mucho hardware, en plan millones de ordenadores (tanto sobremesa como portatiles) en todo el mundo… generas muchísima pasta.

Ahora cambia tu punto de vista: añade a esa gente el resto del mundo que tiene windows/linux con PC’s que casi seguro que se pasarían a Mac OS X y tendrás el 99% del mercado. Teniendo tus millones de dólares por hard y sumándole otros tantos de venta de software.

Uno de ellos, el estar liado estabilizando un blog con 5000-6000 visitas diarias diferente a Anieto2k.

Fue el propio anieto2k quien me “presentó” a Alex, de AlexSEO y BlogHogwarts, siendo este último un blog de Harry Potter. Su problema era el de siempre: mucha visita y el server inestable totalmente.

Por si fuera poco, ya sabemos todos que Harry Potter tiene muchos fans, este blog está alojado en un VPS (para los no entendidos, una máquina virtual). Con 1 giga de ram y, supongo yo, unos 500-600 Mhz de procesador, sin swap alguna (cosas de la tecnología usada por ese hosting), me decidí a mirar si podía estabilizar de alguna manera ese server.

La instalación era una Ubuntu con LAMP y Ricardo Galli ya había pasado por ahí, cosa que dificultaba mi trabajo. No es que odie o ame a Ricardo, pero reconozco que a veces habla con argumento y con empírica.

Tras varios toqueteos, conseguí ponerle eAccelerator (pues estaba instalado pero no se usaba) y medio configuré unos parámetros en Apache. La cosa estaba estable casi siempre, con valores sobre 5-10 de Load Average. Esto no es un gran elogio, pero la media anterior estaba en 15. El problema era que tenía avalanchas de visitas y hacía que el load se subiera a 50 y agotaba toda la ram. Aquello era impracticable.

Decidí mover ficha con algo que tenía medio pensado para NoPuedoCreer. El objetivo era cambiar la pila de Apache+PHP por algo más manejable. Encontré Nginx, un servidor web muy muy ligero con apenas consumo de memoria creado por un ruso. Aunque la opción más lógica era usar Lighttpd, Nginx tiene como punto positivo que las reglas rewrite que suele usar la gente en Apache funcionen a la primera casi sin tener que tocar nada.

Dicho y hecho. La parte de PHP se soluciona haciendo que se procese con el sistema directamente. Y aquí es donde estriba el cambio radical y fundamental: Apache tiene un módulo que directamente ejecuta las cosas en php en el propio entorno del servidor web, haciendo que se consuma mucha más memoria.

Sin embargo, Nginx se configura para que se pasen las peticiones php al comando del sistema directamente, siendo el sistema operativo el encargado de ejecutarlo y tener control sobre memoria. Aunque algunos me tachen de loco o de ‘are you from the past’, para mejorar el entendimiento entre php y nginx se usa php en modo fastcgi (en las librerias del sistema usa la configuración de CGI).

Me configuré un script ejecutado cada vez que se arranca el sistema que se crean 7 procesos php en fastcgi a la espera que Nginx les pase algo por hacer. Dado que BlogHogwarts estaba en un VPS, tuve que poner un script en el cron que cada día haga un kill de estos procesos y los relance de nuevo (se quedaban colgados) – esto no he tenido que hacerlo con Anieto2k.

Así que simplemente copié la configuración referente a eAccelerator del Apache y lo metí en la configuración CGI de php. Acto seguido escribí las configuraciónes referentes al dominio con las reglas rewrite para Nginx, que podeis consultar en este post.

Paré el apache, y arranqué Nginx con los procesos php ya creados.

Et voilá! Resultado: como mucho, el load se pone en 5, sucediendo esto cuando se postea alguna información relevante y se linkea mucho desde diferentes sites a ese blog. Nginx casi no tiene carga, pues todo lo procesa el php con sus procesos. Generalmente el uso más notable es el de la base de datos, siendo este como máximo de un 40-50% en contadísimas ocasiones, lo normal es un 2-5%. Lleva la máquina sin caerse hace bastantes días, y el consumo de memoria es estable sin llegar a consumirse nunca el total.

En la parte del usuario, se notan 3 cosas: la velocidad en general de la web, que se carga cada página de golpe (antes apache procesaba cosas y esperaba a que los procesos php terminaran y seguía mostrando la web – ahora simplemente se procesa todo en el lado php y se muestra de golpe) y que no hay merma de rendimiento aparente.

Tras esto, decidí hacerlo en Anieto2k, sobretodo tras su puesta en escena del GeekTest, que hizo que nos tumbaran la máquina los de Microsiervos. Así que dicho y hecho, mismo proceso mismos resultados. Siendo la máquina que hostea Anieto2k, Filmclub y este mismo blog una máquina dedicada con Debian, el load rara vez pasa de 0.57 y la base de datos se mantiene entre un 20-40% por culpa de los accesos al GeekTest.

Todos estos blogs estan en wordpress 2.5, cosa que aumenta el consumo de CPU+Memoria. Pero como si no lo notara. Podemos tener avalanchas bestias y la máquina sigue respondiendo, sin perder ápice de configuración o trucos usados ya en php.

Recomiendo a todos los que tengan problemas de load, mucho tráfico y simplemente quieran algo más manejable y rápido, que usen este método.

]]> http://www.arlay.net/2008/04/10/como-consegui-estabilizar-anieto2k-y-bloghogwarts/feed/ 24