Sencillamente no entiendo cómo el rendimiento puede oscilar entre completar ~11 millones y ~300 mil trabajos en un día en el transcurso de ~1 semana, manteniendo la misma configuración. Una diferencia de velocidad de ~35x en términos de trabajos por segundo.
En cuanto al uso de la CPU, ha vuelto a bajar a ~15-20%, que es lo habitual. Procesando trabajos a la misma velocidad (lenta).
Solo para aclarar/confirmar, me refería a asignar (no añadir) algunos Sidekiqs exclusivamente para procesar la cola de baja prioridad, ya que parecía que las tareas de baja prioridad se podían procesar a una velocidad mucho mayor y posiblemente no sufrían los mismos cuellos de botella. Especulaba que esto podría explicar por qué los trabajos por segundo pueden variar tan drásticamente (es decir, tareas de baja prioridad ‘fáciles’ atascadas detrás del retraso de la cola predeterminada).
Para aclarar: ¿crees que el rendimiento de PostgreSQL está causando la finalización lenta de los trabajos o solo el evento de alto uso de CPU que noté ayer (que ahora ha vuelto a la normalidad)?
Actualización: Intenté eliminar la cola de baja prioridad y la cola predeterminada varias veces, sin impacto en la velocidad, ya que la cola predeterminada vuelve a crecer inmediatamente. Luego intenté eliminar la cola predeterminada y activar el modo de solo lectura. Esto provocó un aumento drástico en las tareas por segundo, procesando la cola de baja prioridad a una velocidad de unas 100 veces más rápida.
Edición: Parece que incluso con solo una cola de baja prioridad grande, la velocidad de procesamiento sigue siendo lenta. Si configuro Discourse en modo de solo lectura y luego vacío tanto la cola de baja prioridad como la predeterminada, el procesamiento de tareas posteriores parece mantenerse extremadamente rápido, vaciando las tareas programadas y las colas hasta que desactivo el modo de solo lectura.
Mi siguiente paso sería averiguar exactamente qué proceso está causando el problema, entrando en la aplicación de Discourse y ejecutando htop o top para ver el uso de CPU más alto.
Suena como si PostgreSQL fuera el cuello de botella. Podrías configurar Prometheus para rastrear su rendimiento y ver si tiene acceso suficiente a la memoria RAM.
Gracias por tu aporte @pfaffman Creo que db_shared_buffers y db_work_mem en app.yml son los únicos controles para el acceso a la memoria RAM de PostgreSQL, ¿verdad?
He hecho algunas pruebas ajustando los valores tanto hacia arriba como hacia abajo. Los ajustes actuales en app.yml son:
db_shared_buffers: “32768MB”
db_work_mem: “128MB”
Con una memoria RAM total del sistema de 128 GB.
También he intentado modificar max_connections en /var/discourse/shared/standalone/postgres_data/postgresql.conf y luego reconstruir Discourse. Probé valores superiores al predeterminado (100), desde 200 hasta 500. Actualmente está configurado en 300. No estoy seguro de si modificarlo allí realmente cambia el valor máximo de conexiones.
Veo lo siguiente en /var/discourse/templates/postgres.template.yml:
Gracias @bartv, siguiendo tu sugerencia he estado observando desde dentro de la aplicación Discourse mediante top. Veo bastantes procesos postmaster ejecutados por el usuario postgres, con un uso de CPU variable. Las capturas de pantalla representan periodos de tiempo prolongados con estadísticas de uso similares.
Deberías informarte sobre el ajuste de PostgreSQL. Ese nivel de rendimiento está un poco por encima del autoalojamiento típico que se ve aquí.
Yo probaría asignando a PostgreSQL aproximadamente 3/4 de la RAM. Ciertamente, separaría los contenedores de datos y de la web. Pero es posible que necesites una configuración de PostgreSQL más compleja para obtener el rendimiento que necesitas.
EDITO: Pero no tengo experiencia con bases de datos mucho más grandes, ¡así que mira abajo!
He intentado realizar consultas, pero obtengo este error:
ERROR: pg_stat_statements debe cargarse mediante shared_preload_libraries
Mi suposición es que mis ediciones en el archivo postgresql.conf (/var/discourse/shared/standalone/postgres_data/postgresql.conf) no están funcionando (reconstruí Discourse después de editarlas). ¿Es posible realizar estas ediciones a través del archivo app.yml? ¿O ves algo que haya hecho mal?
Reconstruir Discourse borrará esos cambios. Reiniciar el contenedor probablemente hará el truco. (algo como sv restart postgres dentro del contenedor también podría funcionar).
Sin mirarlo realmente, es probable que sea /etc/postgres dentro del contenedor. También es posible que necesites instalar la biblioteca que esté requiriendo.
¡Gracias, esto ayudó mucho, al principio. . El problema parecía resuelto y la cola de trabajos avanzaba muy rápido solo aumentando las conexiones máximas en postgresql.conf. Desafortunadamente, volvió a ralentizarse después de aproximadamente un día.
A continuación, se muestran los pasos, por si son útiles para otros que deseen aumentar el max_connections de PostgreSQL.
docker ps
Obtén el ID del contenedor, por ejemplo aaabbbccc123, y reemplázalo en los comandos siguientes:
Copia el archivo postgresql.conf desde dentro del contenedor Docker al sistema de archivos local:
I can’t really read the result though, I think I’ve done something wrong.
total | avg | query
1671.1110420745 | 374.736186677194 | SELECT COUNT(*) FROM ( +
| | SELECT $1 FROM +
| | notifications n +
| | LEFT JOIN topics t ON t.id = n.topic_id +
| | WHERE t.deleted_at IS NULL AND +
| | n.notification_type <> $2 AND +
| | n.user_id = $3 AND +
| | n.id > $4 AND
Ahora que sabes lo que quieres hacer, puedes realizar estos cambios con una sección de reemplazo en tu app.yml.
También podrías simplemente ejecutar ./launcher enter app y editar los archivos directamente. Ten en cuenta, sin embargo, que al reconstruir, esos cambios no estarán presentes en el nuevo contenedor.
Creo que 
. El problema parecía resuelto y la cola de trabajos avanzaba muy rápido solo aumentando las conexiones máximas en postgresql.conf. Desafortunadamente, volvió a ralentizarse después de aproximadamente un día.