Parada de mantenimiento de emergencia

Actualización: acabó satisfactoriamente a las 2:35, o 0:35 UTC. Disculpad las molestias.

Resumen

Esta madrugada, 20 de setiembre a las 2 AM hora española continental una menos en Canarias, o mejor, a las 00:00 horas UTC cortaremos el servicio por mantenimiento urgente de la base de datos. Esperamos que no tarde más de media hora, pero como el procedimiento es relativamente complejo, podría tomar hasta una hora.

Explicación larga

Llevábamos varias semanas con microcortes (y algunos no tan micro) en Menéame. Se debían a una sobrecarga de la base de datos. Después de optimizar todo lo optimizable, logramos reducir la frecuencia y el efecto negativo, pero aún así, aparecen unas pocas veces al día.

La base de datos central (tenemos otra esclava) es un sistema RDS Multi AZ, consiste de dos servidores, uno siempre es el primario y el otro el secundario. Si el primario falla, automáticamente se migra (failover) al otro que está sincronizado y listo para hacer de nuevo máster.

Nuestro problema eran saturaciones repentinas de la base de datos Multi AZ. Aunque abrimos incidencias y explicamos a soporte de Amazon AWS, aseguraban no encontrar el problema, hasta esta mañana que después que le pasamos más datos. Se pusieron a analizar en profundidad y encontraron el problema: el que tenemos de secundario ahora tiene problemas de hardware que le hace bajar el rendimiento, como está sincronizado con el principal, a veces le provoca esos picos que no puede manejar. Para solucionarlo tenemos que librarnos de ese secundario y hacer que se arranque con uno diferente, es el procedimiento que nos han pedido que hagamos (abajo la explicación del técnico de Amazon).

Para evitar seguir teniendo estos problemas (que sabemos ocurrirán) mañana o los días que demoremos, hemos decidido hacerlo esta misma madrugada, en poco más de dos horas.

Disculpas por esta interrupción, y disculpas por las molestias ocasionadas las últimas semanas. Esperamos que a partir de esta madrugada las cosas funcionen mucho más suavemente.

De nuevo, disculpas.

As you pointed out with the CloudWatch metrics that you noted, your RDS database instance has been experiencing some occasions of increased and unexpected write latencies, which also correlate to a dramatic increase in database connections, and then resulting in issues with the ability to use the database. We drilled down deeper in to the metrics for your RDS instance, and found that a data volume on the Multi-AZ Secondary host system for your RDS database instance has been under-performing. As transactions in a Multi-AZ RDS setup are synchronous, this would cause performance issues to been experienced throughout the transaction process when they happen, such as during your experience.

Given the Mutli-AZ structure of your RDS instance, you do have the ability to take steps to help remedy the situation from your side. We recommend taking the following steps during a time when you can perform database maintenance for your application:
1) Take a database backup snapshot – this is always recommended before performing any maintenance. Also check that your read replica is in-synch for added backup.
2) Update your RDS database instance from Multi-AZ to Single-AZ – this will disconnect and remove the Secondary host system which is currently seen to have the under-performing data volume. It will also place your RDS instance in a state of not having fail-over redundancy, so be sure to have taken a backup snapshot.
3) Once the change to Single-AZ is complete, update your RDS database instance back to Multi-AZ – this will rebuild a new Secondary host system for your RDS database instance, synchronize your data, and restore the fail-over redundancy.

Nuevo algoritmo de análisis y bonificación por diversidad de votos

Desde el 5 de octubre estaba funcionando en pruebas el nuevo algoritmo para controlar la afinidad y favorecer la diversidad de votantes. Tras los últimos ajustes y optimizaciones ya lo consideramos suficientemente estable y fiable como para darlo por “oficial”.

La explicación en detalle de cómo se hace están en Cálculo comparativo de la diversidad de votos mediante densidad de grafos.

Los resultados son buenos (la explicación en el artículo anteriormente citado):

También hemos actualizado el apunte con la explicación sencilla de cómo funciona la promoción de noticias.

Si tenéis dudas o problemas, no dudéis en consultarnos en el Nótame, poned referencia a @gallir o @benjami para que nos enteremos (en Twitter tenemos los mismos nombres).

Explicación simple del algoritmo de promoción de noticias (promote)

Actualización noviembre 4, 2012: Se modifica el punto 4, con la explicación del nuevo algoritmo de afinidad.

Actualización mayo 7, 2009: En la pestaña log de cada noticia se puede observar en qué momento se hicieron los reajustes de karma y las notas informativas del algoritmo.

Siempre que una noticia controvertida con varios votos negativos  (y/o que algunos piensen que no “queremos que salga” aunque le hayamos votado positivo o dado publicidad en nuestros blogs) no sale publicada surgen sospechas o conspiranoias de que “hay manipulación”, aunque el algoritmo de promoción es público, como así también los cálculos que realiza. Sigue leyendo

eMenéame, de cultura y tecnología

Amigos, conocidos y usuarios de Menéame nos dijeron muchas veces:

Hay demasiada política en Menéame, y no hay un espacio para los que están más interesados en seguir sólo temas de Internet, cultura y ciencia.

Aunque hace más de tres años programamos las personalizaciones de páginas -cada usuario puede elegir, en su perfil, qué categorías seguir-, obviamente no ha tenido mucho éxito o popularidad. Hemos reflexionado, si el cliente siempre tiene la razón (o al menos una parte) es que estaba faltando algo más. Por ello fue que creamos eMenéame:

Sigue leyendo