Hola a todos, estoy trabajando en esto con @Abdelrahman_MoHamed. Recientemente migramos un sitio con aproximadamente 500.000 temas y 3,5 millones de usuarios a Discourse. Nos alojamos nosotros mismos en GCP. Durante este proceso, nuestro socio que nos ayudó con la migración mencionó que podría tener sentido optimizar Postgres para obtener un rendimiento adecuado de la base de datos. Nuestra suposición era que la base de datos vendría optimizada para Discourse lista para usar (¿quizás lo está?). Sin embargo, dada su (la sugerencia del socio) queríamos hacer un seguimiento aquí.
En resumen, ¿estas son algunas formas comunes de optimizar Postgres para una base de datos con los números publicados aquí?
¡Gracias de antemano por la ayuda!
¿Tiene pruebas más detalladas de que la base de datos es el factor limitante o la causa de estas cargas de CPU? Por ejemplo, la salida de ps o top.
Si es la base de datos, me imagino que hay alguna forma de preguntarle en qué consultas está trabajando.
Tales detalles podrían ser útiles.
Gracias @Ed_S, pronto agregaremos más datos aquí. Por ahora solo estamos monitoreando las cosas. Agradezco la respuesta.
esa sí que parece una combinación extraña… ¿22 GB de memoria pero solo 4 vCPU? Excesivo en memoria, pero potencialmente muy pocas núcleos.
Normalmente tendrías un servidor con mucha más vCPU por GB.
Eso se debe a que el servicio web es muy paralelo y para cada unicorn solo necesitas alrededor de 1 GB.
Creo que cada Unicorn puede ejecutarse en un núcleo diferente.
Quizás por eso estás alcanzando el 100% de utilización de CPU tan fácilmente.
Te recomiendo que consideres pasar a una configuración 16/16 o incluso 8/8 y veas si las cosas mejoran.
¿Se permite un pequeño rodeo? ¿Son los unicornios algo similar a los trabajadores de PHP? Algún documento intentó explicar que los unicornios son en realidad servidores HTTP con sus propios trabajadores que entregan solicitudes a Ruby, y por eso es totalmente diferente. Pero ambos manejan solicitudes HTTP permitiendo más solicitudes concurrentes y, por lo tanto, más trabajadores de PHP y más unicornios necesitan más RAM, y para mí esas dos cosas son prácticamente lo mismo.
¿Correcto o terriblemente incorrecto? Me gustaría entender el principio ahora, porque sé por qué, cuándo y cómo ajustar los trabajadores de PHP, pero los unicornios son solo criaturas místicas y mágicas para mí.
sí, creo que es una comparación justa
Relacionado: ¿Cómo podría un administrador averiguar si tiene muy pocos o demasiados unicornios para su tráfico web?
Relacionado: ¿Cómo podría un administrador averiguar si tiene mucha más RAM de la que necesita?
Tengo entendido que el número de unicornios generalmente se escala según el número de CPU, pero no tiene por qué ser así; si, por ejemplo, la configuración del host ha cambiado desde la configuración.
La cantidad de RAM debería escalarse según la cantidad necesaria. No sé si una importación masiva de muchas publicaciones y usuarios necesariamente significa que se necesita más RAM; la pregunta sería, ¿cuánta de la base de datos se accede para atender cada solicitud web o cada tarea regular?
Para mí, una ráfaga de 10 minutos de uso máximo de CPU, sobre un fondo de uso muy bajo, no indicaría un problema. (Sería un problema si significara que un foro muy ocupado y crítico en el tiempo, como un foro de deportes/apuestas, tuviera algún retraso en la entrega de páginas en momentos de máximo interés. Pero mi foro no es crítico en el tiempo ni en el rendimiento).
No sé cómo se podría tabular el rango de tiempos de respuesta recientes, pero esa podría ser una buena información para analizar. Ya sea desde el lado del servidor web o desde el lado de la base de datos.
