Hemos restablecido todos los valores modificados a los predeterminados y actualizado a la versión 2.6.0 beta4. Los juegos se llevarán a cabo el jueves y el viernes, por lo que tendremos una buena cobertura de pruebas más adelante esta semana.
Lamentablemente, la solución no resuelve el problema. Tuvimos un juego moderadamente activo con 600 mensajes. Se observaron varios congelamientos tanto en mis pruebas como entre nuestros miembros. Estos coinciden con eventos del juego, es decir, picos de actividad.
- El uso de CPU estaba muy por debajo de los límites, alcanzando un máximo de alrededor del 60% y una carga promedio de alrededor del 30%.
- Definitivamente es un problema del lado del cliente. Cuando el tema del chat se congela, si vas a la página de inicio verás el número de publicaciones sin leer. Vuelve al tema y las publicaciones se volverán visibles.
Lo que todavía me intriga, y que no se aborda en este tema, es qué ha cambiado desde la v2.3, que no tenía este problema.
Las actualizaciones principales 2.4 y 2.5 ocurrieron durante nuestra temporada baja (extendida por la COVID), por lo que nadie notó nada, pero los congelamientos fueron evidentes de inmediato en el primer partido de exhibición de la pretemporada.
¿Hay alguna manipulación de parámetros que podamos probar para mañana? Será un derbi intenso y un partido como visitante, así que la comunidad estará al rojo vivo.
En nuestro caso, desactivar el plugin ¿Quién está en línea? y deshabilitar el archivo de limitación de velocidad (y leí que hubo algunas mejoras con la beta más reciente) pareció funcionar para nosotros.
Ahora también tenemos partidos de fútbol de vez en cuando con 300 usuarios o un poco más haciendo clic y escribiendo todos en el mismo tema al mismo tiempo, y pareció funcionar mucho mejor durante el último partido.
¿Estás en la última versión, con la corrección reciente?
Por favor, actualiza para que las pruebas pasen. He perfeccionado muchas cosas desde la beta.
Sí, la última versión beta (es decir, hasta las últimas 48 horas).
Actualizado. El informe seguirá.
Por desgracia, sigue sin ser viable. Por supuesto, el juego estuvo muy activo con 950 mensajes. Estuve pendiente de GAnalytics y había alrededor de 250 personas observando, de las cuales 119 publicaron. Se observaron varios congelamientos, como antes. El bus de mensajes ha devuelto algunos errores 429, con los mensajes “Has realizado esta acción demasiadas veces, espera X minutos”.
La carga de la CPU alcanzó un pico de ~70% y prácticamente no hubo tiempo de espera (wa). Así que, aunque la actividad fue alta, todavía no podemos ofrecer lo que el hardware sería capaz de entregar.
¿Podrías responder a la única pregunta que me ha desconcertado: qué se ha implementado después de la versión 2.3 que está causando esto y qué se supone que debe aportar?
La implementación es prácticamente la misma que siempre, excepto que ahora tenemos límites de tasa globales para la aplicación, los cuales son configurables. Puedes aumentarlos si lo deseas, aunque podría provocar un colapso total; no lo sé.
No entiendo a qué te refieres con “congelamientos”. Si el sistema queda demasiado saturado ahora, dejará de actualizarse, pero la diferencia es que ya no necesitas recargar el navegador para arreglar la página; se recuperará automáticamente una vez que el servidor tenga capacidad disponible.
Esto queda un poco poco claro: ¿tus usuarios están observando que no hay ninguna mejora tras mis cambios?
¿Tu servidor tiene mucha memoria RAM libre? Si es así, agrega más trabajadores de Unicorn.
¿Qué valor tiene el parámetro db_shared_buffers? Al principio tuvimos mucho comportamiento “inestable” (algunos temas “consumían” muchos recursos, especialmente cuando tenían mucha participación) con solo el 25% recomendado de la RAM total. Cuando lo aumentamos a 16 GB (de 32 GB), toda esa inestabilidad desapareció… y más recientemente, con los últimos cambios, ha mejorado aún más.
Bueno, este fenómeno es difícil de monitorear en un entorno de producción (como los chats de juegos), ya que cada juego es diferente: distinta cantidad de eventos críticos, diferentes oponentes, distinta carga emocional, etc.
El problema, desde nuestra perspectiva, es que nuestra capacidad máxima de servicio ha disminuido desde la versión 2.3. Ese es el punto clave. Cada servidor tiene sus límites, pero ahora estamos obteniendo menos rendimiento del nuestro que en marzo, cuando ejecutábamos la versión 2.3. Según un monitoreo aproximado del backend, el servidor no puede alcanzar el 100 % de carga o capacidad.
Lo que ve el usuario final es que el flujo del chat simplemente se detiene, sin ninguna indicación en la interfaz de usuario sobre lo que está ocurriendo. Eso genera confusión.
Estoy bastante seguro de que los cambios en los tests pasados han mejorado la situación, pero el rendimiento o la salida máxima sigue siendo significativamente menor que con la versión 2.3.
Tenemos un VPS con 6 núcleos rápidos y 16 GB de RAM. Los Unicorn están configurados en 12, y la configuración relacionada con el búfer de RAM está en sus valores predeterminados.
Creo que el mejor siguiente paso aquí es configurar el monitoreo histórico de tu sistema para que podamos identificar dónde está el cuello de botella, ya que hemos establecido que no se trata del tiempo de CPU. Siempre es posible que estés saturando tu conexión de red.
además de métricas de servidor más tradicionales como node-exporter.
Si este es el caso y deseas exigirle más al servidor:
-
Puedes reducir los límites de tasa; esto permitirá que los usuarios interactúen de manera más agresiva con Discourse. Específicamente, podrías duplicar
DISCOURSE_MAX_REQS_PER_IP_PER_MINUTEyDISCOURSE_MAX_REQS_PER_IP_PER_10_SECONDS. -
Puedes intentar agregar más trabajadores de Unicorn.
Esto es temporalmente esperado mientras estás sobrecargado, pero el sistema debería recuperarse automáticamente una vez que la carga disminuya.
Mi suposición aquí es que todo esto está relacionado con los límites de tasa; estos límites son nuevos y están diseñados para proteger el servidor. Parece que tu servidor está siendo protegido por diseño.
Probamos un juego con…
DISCOURSE_REJECT_MESSAGE_BUS_QUEUE_SECONDS: 0.3
DISCOURSE_MAX_REQS_PER_IP_MODE: none…y cuando las emociones empezaron a caldearse en el tercer periodo, las cosas empeoraron. Alcanzamos los límites de nuestros servidores; los usuarios eran constantemente expulsados al estado de desconectado y el chat del juego también se congelaba.
Fue una gran historia de éxito durante 4 años, pero ahora nos encontramos en una situación muy complicada. Saltar al siguiente nivel de capacidad de VPS nos llevaría a la categoría de precios de ~160 €/mes, lo cual es un desafío para un sitio de afición. Tampoco estamos hablando de volúmenes de usuarios enormes: 116 personas publicaron más de 800 mensajes durante el juego.
La ideología de «no hacer chats» tampoco es adecuada. Si no los tuviéramos, las publicaciones de reacciones emocionales se dispersarían por todos los temas más «serios». Son una herramienta importante para canalizar la carga emocional de la situación en vivo hacia un solo tema, manteniendo los temas más analíticos limpios.
El mío es un foro de fútbol y he experimentado desafíos similares.
Básicamente, lo que descubrí fue que se trataba de un problema de escalabilidad.
Los problemas para mí comenzaron en diferentes niveles.
Digital Ocean
1 CPU y 1 GB = 30-40 usuarios en una situación similar a un chat
2 CPUs y 2 GB = 70-80 usuarios en una situación similar a un chat
4 CPUs y 8 GB = adecuado para 120 usuarios y 1000 publicaciones en 2 horas. No llegué al límite.
Estoy probando diferentes niveles de mejora con Hetzner (sitio espejo) ya que es más barato, pero no ha ido tan bien como esperaba.
Mi experiencia hasta ahora es:
3 CPUs (chip AMD CPX 21) y 4 GB = luchando con 20 usuarios
2 CPUs (Intel) y 8 GB = sin problemas con 20 usuarios.
Estoy a punto de probar con 80 a 100 usuarios simultáneos bajo condiciones de partido.
Cuando revisé el uso de CPU en Digital Ocean, incluso bajo estrés, el uso de CPU parecía bastante bajo <50% en todo momento en todos los niveles.
Cuando revisé el uso de CPU en Hetzner para el chip AMD, veía un uso mediano de CPU de alrededor del 60%, pero cada minuto o así, un pico breve hasta el 300% del uso de CPU. Esto no parecía ocurrir con el chip Intel.
No sé lo que esto significa. Sospecho que el monitoreo de CPU es mejor en Hetzner (capturando picos breves). Pero en general, el uso de CPU parece estar bien equilibrado. Digital Ocean, a primera vista, parece manejar mejor los picos, pero debería tener más información sobre Hetzner después de este fin de semana.
También debo añadir que, con la prueba de Hetzner, el plugin ‘whose online’ no marcó ninguna diferencia.
Sin embargo, el plugin de mensajes rápidos de Discourse pareció ser perjudicial.
El próximo juego está programado para mañana. Hemos eliminado nuestros propios parches y estamos probando con estas opciones.
Además, como un intento desesperado, he aumentado db_shared_buffers de 4 GB (25 %) a 6 GB (37,5 %). También he descomentado la línea db_work_mem de 40 MB en app.yml (por cierto, esta es una opción muy poco documentada, aunque se presenta al administrador como una especie de oportunidad de mejora).
Ya no espero encontrar una solución definitiva para el problema, sino solo un mejor control de daños: un conjunto de parámetros que tenga el menor impacto negativo en la experiencia del usuario final. Mientras tanto, tendré que explorar las posibilidades para aumentar aún más nuestros recursos de alojamiento.
Pregunta para @sam y otros desarrolladores.
¿Cómo afecta el tamaño en constante crecimiento de la base de datos a este caso de uso, donde los usuarios bombardean un solo tema durante un par de horas?
Revisé la actividad histórica de los chats de juegos y noté que teníamos partidas con estadísticas enormes en 2017, cuando nuestro servidor tenía una fracción de los recursos que tenemos hoy. Tuvo partidas donde la cantidad de mensajes alcanzó los 1600 por 165 usuarios y nadie se quejó del rendimiento. Ahora no podemos manejar ni la mitad de eso, con un servidor mucho más potente.
Podrías probar aumentándola a 80 MB. Quizás en lugar del otro cambio.
Este es un punto en el que estamos trabajando activamente todo el tiempo.
Cuando Discourse era nuevo, casi todos los sitios tenían una base de datos completamente nueva, por lo que la base de datos podía caber fácilmente en la memoria. Ahora, unos años después, algunos sitios tienen bases de datos de más de 100 GB y tamaños de RAM que ni siquiera representan una décima parte de eso.
Una actualización próxima en las próximas semanas es la actualización a PostgreSQL 13, que reducirá a la mitad el tamaño del objeto más grande.
Aparte de eso, el paso 0 para depurar tus problemas de rendimiento es recopilar datos con el plugin exportador de Prometheus para Discourse, para que no estemos volando a ciegas.