Para colores, 32 Bits

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.

Lea el resto »

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.

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.

Lea el resto »

2. Copiar al estilo linuxero.

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).

Lea el resto »

Ya tardábamos en liarla con el servidor nuevo.

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/0x7a
Jan  3 12:34:13 NaRRa kernel: [41979.813366]  [<ffffffff802461b2>]
autoremove_wake_function+0×9/

Ahora parece que aguanta sin problemas

Psystar, la empresa que ha pasado a ser conocida por toda la blogosfera maquera por empezar a vender su OpenComputer, ha dado señales de vida. Concretamente, su presidente, Rudy Pedraza, ha realizado algunas declaraciones el sitio web Forbes.

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.

Lea el resto »

Puede parecer extraño, la verdad es que llevo casi 1 mes sin actualizar por varios motivos.

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.

Lea el resto »