Si bien, en general, las cosas fueron bien, después surgieron problemas con los procesos de Postgres que consumían el 100% de un núcleo. Sin embargo, los números de procesos variaban. Intenté varias cosas, desde una reconstrucción hasta reinicios. Actualmente estoy intentando un rake db:validate_indexes que ya lleva varias horas en ejecución sin ninguna respuesta. No estoy seguro de si había hecho esto antes y si se supone que debe ser más rápido.
Usar el foro funciona bien básicamente, pero definitivamente se ha ralentizado. Algunas tareas de ejecución más larga, como cargar perfiles de usuarios más activos, tardan notablemente más de lo habitual.
Estoy bastante seguro de que hay algunos problemas con la base de datos, pero me cuesta mucho averiguar cuáles son.
Tengo que decir que nuestra base de datos es bastante grande: tenemos alrededor de 150 GB después de la restauración y después de la creación de índices. Al monitorear el proceso de restauración, no he visto ningún error y la creación de índices salió bien a mi parecer.
¿Alguna idea sobre cómo abordar esto? Actualmente son 3 procesos de postgres; antes de un reinicio que hice hace unas horas eran 6; también he visto que se utilizaron los 16 núcleos después de la restauración.
EDITADO: Acabo de notar ahora que 3 procesos de sidekiq están ocupados con “indexando categorías para búsqueda”. ¿Podría ser todo esto simplemente la reconstrucción del índice de búsqueda? Si es así, ¿se puede resolver de otra manera? Cuando hagamos la restauración del sistema en vivo, esto será un gran problema si degrada el rendimiento durante varias horas o incluso días.
Ahora mismo solo hay una tarea de sidekiq ejecutándose con “Jobs::BackfillBadge”, pero todavía hay 7 procesos de postgres que parecen estar bloqueando el 100% de la CPU constantemente. Tengo mucha curiosidad por saber qué está pasando ahí.
No estoy seguro si está haciendo algo, pero ha estado ahí durante más de 30 minutos.
Puse el foro en modo de solo lectura y reinicié la VM para finalizar los 7 procesos de Postgres que estaban “atascados” allí antes. Poco después del reinicio, 2 de estos procesos de postgres volvieron y no cambiaron. No hay nada ejecutándose en sidekiq en este momento.
Realmente no querrás ejecutar un VACUUM completo. Todo lo que necesitas para recuperar el rendimiento es un VACUUM VERBOSE ANALYZE. No puedes ejecutar un FULL en un sitio en funcionamiento.
¡Ajá! ¡Un consejo sensato de un experto! Así que tal vez tenía razón en que 8 GB/25% no es suficiente, y aunque 16 GB es más del 40%, podría seguir siendo una buena sugerencia porque…
Chicos. como se dijo, este es un servidor de prueba, no hay tráfico en él. Este servidor definitivamente no es lo suficientemente bueno para uso en producción, pero ese no es el problema aquí. La pregunta es por qué vemos procesos de postgres atascados de esa manera (con un 100% de uso de CPU) y ralentizando las cosas drásticamente. Estábamos ejecutando el servidor de prueba con menor capacidad incluso hasta hace unos días; solo se amplió debido a la falta de espacio en disco para una restauración.
La máquina de producción se está ejecutando con 128 GB de RAM con la misma configuración de búfer compartido sin problemas; por lo tanto, no creo que haya un problema general con estas configuraciones y el tamaño del búfer compartido, especialmente no en una máquina de prueba privada sin tráfico.
Pero de todos modos, simplemente rehaceré la restauración y veré si algo salió mal, ya que aparentemente no hay una buena explicación para el comportamiento.
¿Postgres