Error de carga extrema después de actualizar a 3.3.0.beta3-dev ayer (en Prem)

Actualizado a 3.3.0.beta3-dev ayer y también instalado el plugin de IA. El plugin está actualmente habilitado solo para miembros del personal (5 personas)

Pero todo el sitio es extremadamente lento, estoy experimentando errores de carga extremos. No puedo averiguar de dónde viene, la carga de mi servidor parece estar bien.

¿Hay algún lugar o lugares a los que pueda ir para averiguar qué lo está causando?

Aquí está lo que veo en el Informe del Rastreador, no estoy seguro si es bueno o malo o qué. No tengo un marco de referencia.

Mirando mi servidor, parece que los procesos de unicorn están bastante ocupados

¿Es esta la causa? ¿Necesito más CPU? ¿O solo más Unicornios?

¿Ha pasado mucho tiempo desde tu última actualización? Quizás esté realizando algún tipo de procesamiento de imágenes o volviendo a hornear.

Puedes echar un vistazo a /sidekiq para ver qué está haciendo.

Colas Vacías

Realmente no sé qué significa el resto.

No estoy seguro de qué es normal aquí… Aquí están las especificaciones de nuestro servidor
image

Reinicié todo y volvió a la normalidad, pero ahora estamos experimentando una carga extrema nuevamente. No puedo averiguar de dónde viene el problema, ¿hay alguna herramienta que pueda ayudar dentro de Discourse?

Así que los 3 unicorn workers
image

Están ocupados… pero no estamos obteniendo más tráfico del normal, por lo que puedo decir, es el mismo que ha sido, el único cambio fue la actualización a 3.3.0 y se agregó el plugin de IA, pero solo está disponible para el personal.

Los problemas comenzaron ayer 6/3

Parece que tenemos algunos rastreadores más.

Aquí solo hay rastreadores durante un mes, pero de nuevo, no parece mucho más alto. El sitio es casi inutilizable.

¡Cualquier ayuda sería apreciada!

Esta es una suposición, pero lo único que me llama la atención en los registros de Sidekiq es que el trabajo que se muestra es NotifyMailingListSubscribers. Ese trabajo puede crear potencialmente muchas solicitudes.

Además, ¿ves algún error en tu página de Administrador / Registros / Registros de errores?

Agregué un bloqueo al rastreador de Facebook porque ese tipo se estaba descontrolando
image

Sin embargo, noté que agregar lentos / rastreadores no actualiza mi robots.txt

pero robots.txt no muestra las entradas lentas, solo las entradas de bloqueo.

Unos cuantos de estos

Veo 3 errores pero no parecen estar relacionados… (aunque es difícil decirlo)

Excepción de trabajo: PG::DatetimeFieldOverflow: ERROR:  timestamp fuera de rango: \"271768-09-23 06:24:11.793040 BC\"
LÍNEA 1: ...sers\".\"moderator\" = FALSE AND (users.created_at < '271768-09...
                                                             ^
ActionDispatch::RemoteIp::IpSpoofAttackError (¡¿Ataque de suplantación de IP?! HTTP_CLIENT_IP=\"10.10.121.119\" HTTP_X_FORWARDED_FOR=\"14.140.10.244, 14.140.10.244\")
app/controllers/topics_controller.rb:1298:in `track_visit_to_topic'
app/controllers/topics_controller.rb:169:in `show'
app/controllers/application_controller.rb:422:in `block in with_resolved_locale'
app/controllers/application_controller.rb:422:in `with_resolved_locale'
lib/middleware/omniauth_bypass_middleware.rb:64:in `call'
lib/content_security_policy/middleware.rb:12:in `call'
lib/middleware/anonymous_cache.rb:391:in `call'
lib/middleware/csp_script_nonce_injector.rb:12:in `call'
config/initializers/008-rack-cors.rb:14:in `call'
config/initializers/100-quiet_logger.rb:20:in `call'
config/initializers/100-silence_logger.rb:29:in `call'
lib/middleware/enforce_hostname.rb:24:in `call'
lib/middleware/request_tracker.rb:291:in `call'

Y otra excepción de trabajo sobre SMTP

Discourse realiza su propio control de velocidad, no depende de robots.txt

Gracias Michael,

¿Alguna otra idea de qué podría ser? ¿Ayudaría girar más unicornios?

¿Eso se hace desde el app.yml?

Sí, probablemente ayudaría.

env:
  UNICORN_WORKERS: 8

en el app.yml hará esto.

Recomiendo obtener números de rendimiento utilizando el plugin prometheus si lo tienes configurado, o puedes usar encabezados de rendimiento.

Analizar tus registros web debería ayudar mucho a identificar por qué tu servidor está tan ocupado; parece que los rastreadores son un buen lugar para empezar.

2 Me gusta

¡Bueno, actualizamos a una nueva instancia de DO, duplicamos la RAM y la CPU. Añadimos 8 unicornios (vs 3), hicimos una reindexación y un vacuum de la base de datos y ¡creo que hemos vuelto al negocio!

Gracias por la ayuda.

3 Me gusta

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.