Abstract

El día 16 de marzo la página yonkis.com enlazó al wiki de Oasi, en concreto la página con las frases de Chuck Norris. El servidor murió.

En este artículo se analiza la muerte temporal del servidor, si ha tenido relación con el denominado “efecto yonkis” y otras consideraciones sobre redes y configuración de servidores.

Las máquinas

Las máquinas implicadas en el informe son las siguientes:

  • Oasi, un AMD64 3200+ con 1 GB de RAM y corriendo Gentoo Linux con runlevel de modo texto. Tiene servicios de correo, SSH, web (páginas estáticas, dinámicas y mediawiki) y da servicio a unos 30 usuarios, quizá más.
  • Moskovskaya (jabber.upc.es), un P-350 con 100MB de RAM y corriendo Debian Stable en modo texto. Tiene servicios de jabber, y web (páginas estáticas únicamente). No da servicio a ningún usuario, aunque mi blog está alojado allí por una historia también larga de explicar.

Informe

Ese día kiusap (BOFH de oasi) y yo (BOFH de jabber.upc.es, referido aquí por su hostname: Moskovskaya) intentamos por todos los medios levantar el server. Estaba caído sin motivo, tras analizar los logs vimos que hay un HD petado. Esto hacía que no se pudieran servir las páginas.

En principio consideramos la posibilidad de que hubiera petado la placa base, ya que el antiguo server (p-1000 con 512 de RAM) petó siguiendo el mismo patrón:

  • Deja de responder sin motivo aparente
  • Responde a pings pero no a SSH
  • Se reinicia y a los pocos segundos muere otra vez.

Sin embargo, viendo que podíamos controlar el load average apagando el apache, se descartó esta posibilidad.

Entonces pensamos que podía ser el “efecto yonkis”, pero tras mirar las visitas vimos que llegaban mediante goteo continuo, al ritmo de una cada 1-2 segundos. Esto, amigos míos, no es nada para nuestro hardware: un AMD64 con un giga de RAM.

Pensando que podía haber un bug en mediawiki o MySQL, creamos un HTML estático con el contenido del artículo para evitar todas las peticiones SQL y el procesado PHP. Fue inútil, pues seguía petando el apache.

Redirigimos entonces la página del wiki en cuestión, filtrando por referer, a un mirror que montamos deprisa y corriendo: http://weblog.topopardo.com/frases_de_chuck_norris.html mediante el .htaccess, enviando un código HTML redirect. Se usó el mismo HTML del intento anterior, y se consiguió meter el CSS para que pareciera un artículo wiki. Dio el pego muy bien.

Esto es automático, se sirve desde RAM y no provoca lecturas al disco ni uso de CPU. El servidor seguía muriendo igualmente. Consideramos meter el mirror en chikimarti (un AMD 2400+ con 512 MB de RAM), pero como no pudimos contactar con dzpm (su BOFH), copiamos el código de la página en un html estático y lo redirigimos a moskovskaya.

Sin embargo, el servidor seguía muriendo sin motivo alguno; el coste de servir un HTTP redirect mediante .htaccess es irrisorio, pero el load average se disparó hasta 50

No queríamos desaprovechar el potencial de colaboradores que podía traer un enlace puesto en yonkis, la página española que mueve a más gente. Se envió un correo a los webmasters de yonkis.com para avisarles de que, por favor, cambiaran el enlace de Oasi al nuevo mirror en Moskovskaya. El link estuvo petado hasta el día siguiente, por lo que debe tenerse en cuenta que evitamos la embestida inicial de visitas, la que viene cuando la entrada en yonkis está al principio de la web.

Datos de visitas

Para poder justificar nuestras reflexiones, nos fijamos en datos objetivos y en nuestra corta experiencia como BOFHs

Viendo hoy el tráfico de moskovskaya y oasi, concluimos que:

  • El enlace de yonkis ha movido 1100 visitas a Oasi hasta que éste murió.
  • Tras la redirección y el nuevo enlace, ha movido 20.000 visitas nuevas y 70.000 accesos nuevos a moskovskaya, y subiendo.
  • El primer día, el más peligroso para el servidor por la avalancha, el goteo de visitas (no accesos) era de una cada 1-2 segundos, y las peticiones se resolvían al instante. El load average de moskovskaya no ha llegado a 1.
  • De las visitas a moskovskaya, se han hecho clic en los links al wiki de Oasi más de 2000 veces. De toda esta gente se han registrado (creo) entre 5 y 10 personas nuevas en el wiki, alguna de ellas ha aportado contenido.

Balance

El truco de usar el mirror con una web estática, IMHO, ha sido acertado. Los enlaces a Oasi eran funcionales pero sin embargo la “embestida” de visitas ha sido aplacada por moskovskaya. El HD de Oasi sigue cascado pero, por algún motivo desconocido, al levantar el apache de nuevo ya no muere.

Respecto al llamado “efecto yonkis”, concluimos que:

  • Viendo los logs de moskovskaya, esta carga es mínima. Incluso para el subidón de visitas. He estado todo el día monitoreándolo y cada petición se servía en menos de 1 segundo.
  • Esta carga, soportada por un p-350 con 100 MB de RAM, es imposible que hubiese tumbado a un AMD64 3200+ con 1 GB de RAM. Ni aun con páginas dinámicas.
  • Por si la premisa anterior era errónea, se montó una página estática, idéntica a la ahora existente en moskovskaya. El servidor tampoco la aguantó
  • Por tanto, el día 16 y 17 el server estuvo caído por culpa del disco duro y no del “efecto yonkis”

Llevamos algunos días dándole vueltas a la cabeza y, aun sabiendo el aumento de visitas que implica un enlace desde yonkis, estamos seguros de que no fue la causa (única) que tumbó al servidor

Moskovskaya ha sido enlazado varias veces desde barrapunto y osnews.com. Barrapunto acostumbra a proporcionar unas 3.000 visitas, mientras que osnews provocó 50.000 visitas en un par de días. El server nunca se ha immutado ante esto. La gente a la que le tumban el servidor tiene graves problemas de configuración, páginas dinámicas inútiles o un mal ISP con un mal ancho de banda.

Sigo reafirmándome en mi opinión de que no existe el llamado “efecto XXX”. Yonkis ha provocado 100.000 accesos y 14.000 visitas en un solo día para un PC tan limitado como moskovskaya y el servidor ni siquiera se ha immutado. Quizá un aluvión de slashdot sí pueda tumbar un servidor, pero no puedo saberlo porque nunca lo he experimentado. Algún día lo intentaré.

Conclusiones técnicas

El tiempo de CPU para servir una página estática es mínimo, pero el tiempo de query y PHP de un ordenador tan brutal como el servidor también es mínimo. Además el wiki y el apache implementan caché, ¿no habéis notado que la portada del wiki se carga rapidísimo? Cuando recibe muchas visitas la sirve de caché y no de disco.

Pienso que la caída del server fue provocada por la petada del HD, y el link de yonkis fue pura coincidencia. No puedo demostrarlo, pero creo haber aportado pruebas suficientes para ello

Muchas de las visitas de yonkis clicaron en los enlaces del mirror que apuntaban al wiki, éste aguantó, y un buen número de ellos se ha registrado y/o ha colaborado en el wiki. Esto ha sido muy positivo para la asociación

Consejos para admins

Ni yonkis, ni osnews ni barrapunto mueven suficiente tráfico como para tumbar un servidor. Sin embargo un PC mal configurado puede contribuir a ésto:

  • Si se detecta un link entrante de yonkis u otra página que mueva más tráfico, y este enlace tan sólo se refiere a una sola página de nuestro servidor, quitar todo código dinámico y transformar la página en estática. Fin del problema
  • Asegurarse de que Apache tenga bien configurada la caché de páginas.
  • Si hay problemas de ancho de banda, activar mod_gzip. Gzip, no obstante, chupa más o menos CPU. Se puede desactivar si, como nosotros, estamos conectados directamente a Rediris (aunque no lo hicimos)
  • Aunque haya gente que piense lo contrario, sigo defendiendo a ultranza que para un PC que actúe como servidor no hay distro mejor que Debian. Ni la gentoo superoptimizada del servidor. Debian. Estable. Modo texto. Configurada de forma conservadora.
  • Si algo pasa en un servidor linux, seguro que es el hardware.
  • Páginas estáticas. ¿Os lo había dicho? Ah, como veinte veces… Repetid conmigo: Páginas estáticas. Páginas estáticas. Páginas estáticas…
  • Le pueden dar por culo al Windows Server 2003. Un P-350 con 100 MB de RAM, si está cuidado y mimado, aguanta lo que le echen. ¡Con páginas estáticas!

Fin

Podéis dejar comentarios por aquí. Otra gente ha analizado el efecto barrapunto, pero tenían algunos factores en contra. Daniel Clemente sufrió el efecto barrapunto y se le saturó su red porque era un ADSL casero. Otros tienen problemas con el hosting contratado, porque les limita el ancho de banda. Otros tienen configurado el servidor con el ojete o con CMS que hacen 30 peticiones SQL para servir un pedazo de texto y luego dicen ¡me han barrapunteado!. No, hijo mío, te has barrapunteado tú solito.

Agradecimientos a kiusap por salir corriendo del curro para mirar qué le pasaba al server, a UPCNet-Rediris por su ancho de banda infinito y a Bill Gates por decir que Windows Server 2003 te ahorra dinero. Cómo nos hemos reído al comentar esto en el bar… estoy seguro de que ni siquiera se dejaría instalar en moskovskaya. También a los admins de yonkis.com por su paciencia y por cambiar el link de Chuck Norris tres o cuatro veces.