Plots2: Investigación de problemas de memoria (¿fugas?)

Tomando nota del comentario de

Me pregunto jywarren porque había editado docker-compose-production.yml para usar menos procesos (no hice un PR para ello). Así que podría ser que lo hiciéramos encajar de esa manera.

Y este gráfico:

También estamos viendo muchos errores de prueba de SMTP:

Enlace: | https://intelligence.rackspace.com/cloud/entities/en45StuOyk/checks/chXoX9GHhF/alarm/alycd3HZyu

Sí, la carga también es muy alta. Desde htop y especialmente iotop parece que mailman está bastante activo. ¡Seguro que es el culpable! Antes del 22 de mayo, lo ejecutamos varias veces al día, si podemos ejecutarlo cada pocos minutos, más o menos (¡no cada segundo!), ¡Estaría bien!

I, [2019-05-07T23:56:44.702410 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-08T21:33:03.762360 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-09T07:47:27.518491 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-09T08:18:47.825703 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-10T08:14:53.010705 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-10T21:45:50.739207 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-11T17:38:51.647335 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-13T03:33:15.682877 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-14T05:51:40.603184 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-14T05:53:20.857041 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-14T05:55:00.356772 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-14T05:56:40.487219 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-15T01:43:42.908744 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-16T10:13:45.703985 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-18T12:57:16.194957 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:49:27.019569 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:49:55.827419 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:50:18.722700 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:50:41.709075 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:51:00.124271 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:51:17.146210 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:51:33.745494 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:51:51.387282 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:52:09.145006 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:52:31.266559 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:53:03.176998 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:53:26.991989 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:53:54.074275 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:54:13.905343 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:54:37.736641 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:54:57.357057 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:55:15.522535 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:55:34.343241 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:55:51.964241 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:56:10.016964 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:56:42.822692 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:56:59.826809 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:57:16.178517 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:57:35.871196 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:57:59.731422 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:58:16.353160 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:58:33.608591 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:58:50.037296 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:59:06.912680 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:59:32.287362 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:59:59.201948 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T09:00:18.739067 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T09:00:42.144910 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T09:01:03.495556 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T09:01:20.493712 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T09:01:37.089192 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T09:01:53.921571 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T09:02:14.509227 #1]  INFO -- : Mailman v0.7.0 started

El registro está lleno de ciclos de estos, no hay error:

I, [2019-06-02T02:35:26.270644 #1]  INFO -- : Mailman v0.7.0 started
I, [2019-06-02T02:35:26.270851 #1]  INFO -- : Rails root found in ., requiring environment...
I, [2019-06-02T02:35:56.930267 #1]  INFO -- : POP3 receiver enabled ([email protected]@pop.gmail.com).
I, [2019-06-02T02:35:56.938850 #1]  INFO -- : Polling enabled. Checking every 5 seconds.

¡Parece que el cartero se está cayendo y está reapareciendo de inmediato!

icarito@rs-plots2:/srv/plots_container/plots2$ docker ps
CONTAINER ID        IMAGE                COMMANDCREATED             STATUS              PORTS NAMES
8d13c675568e        containers_mailman   "script/mailman_serv…"4 days ago          Up 14 seconds containers_mailman_1
f423dec91ebe        containers_web       "/bin/bash -c 'sleep…"4 days ago          Up 4 days           127.0.0.1:4001->4001/tcp containers_web_1
24f7b43efebc        containers_sidekiq   "bundle exec sidekiq…"4 days ago          Up 4 days containers_sidekiq_1
070511ab43d1        redis:latest         "docker-entrypoint.s…"4 days ago          Up 4 days           6379/tcp containers_redis_1
6ea8f0498b2c        mariadb:10.2         "docker-entrypoint.s…"4 days ago          Up 3 days           3306/tcp containers_db_1

Decidí detener este contenedor por esta noche para monitorear el efecto en el rendimiento.

Creo que también podemos ver qué actualizaciones de gemas se fusionaron en los días previos a la publicación de este código. ¡Gracias!

Eso es tan extraño sobre mailman, miraré la configuración pero no recuerdo ningún cambio en la tasa.

Oh, ¿sabes qué? Lo configuramos para que vuelva a intentarlo 3 veces. ¿Quizás estos se superponen ahora? Al menos podría haber aumentado la tasa de intentos, ya que vuelve a intentarlo 3 veces por cada ejecución programada.

https://github.com/publiclab/plots2/blob/faf66c0b15473add33c10c47d57a6e7cc46ea669/script/mailman_server#L32

Ok lo modificó durante 20 segundos, lo que debería significar un reintento máximo cada 5 segundos -

https://github.com/publiclab/plots2/commit/a40ea5650f2ce9ec80ee2324cea2d8c9bd98e382

Será la misma tasa que antes cuando agregamos reintentos.

Bien, ahora trabajando en el análisis después de unas horas:

https://oss.skylight.io/app/applications/GZDPChmcfm1Q/1559574420/6h/endpoints

En general se ve bien. Pero, al mirar más de cerca, está aumentando el tiempo de carga:

Comparando la última parte donde está comenzando a volver a subir:

al anterior justo después del reinicio:

Y luego a esto de hace un par de semanas antes de todos nuestros problemas:

Luego, finalmente, justo después de que comenzamos a ver problemas el 22 y 23 de mayo:

En general, no es concluyente.

Recursos:

• una lista de gemas y versiones con fugas de memoria: https://github.com/ASoftCo/leaky-gems
• https://samsaffron.com/archive/2015/03/31/debugging-memory-leaks-in-ruby

Una de las cosas difíciles de esto es que es justo donde ocurrieron estas dos confirmaciones:

1. deshabilitar el almacenamiento en caché en los perfiles (que luego revertimos): https://github.com/publiclab/plots2/commit/794df370264a605935483aa8d0e4946bfd14c37c
2. el proceso de construcción del contenedor cambia: https://github.com/publiclab/plots2/commit/794df370264a605935483aa8d0e4946bfd14c37c

Me gustaría pensar que se relaciona con la adición del código retry 3 times en https://github.com/publiclab/plots2/commit/2bc7b498ef3a05bc090ef26f316a30ec0104bcc6 , que intenté modificar hoy. Pero, en realidad, los tiempos de carga siguen aumentando lentamente.

Esto podría significar que a) algo más lo está impulsando, ob) el ciclo de "rescate / reintento" en sí mismo podría estar causando una pérdida de memoria.

¿Debo comentar el código de rescate / reintento por completo?

tal vez el colgante esperando a que mysql se recupere en realidad está tomando hilos

Intentaré esto. El sitio casi no responde.

Eliminé el retry aquí: https://github.com/publiclab/plots2/commit/faa5a12e86bf7944dca43134f649947f03ca96a6

Implementar ... llevará un tiempo.

Hmm, realmente no parece resuelto ... https://oss.skylight.io/app/applications/GZDPChmcfm1Q/1559577660/8h13m/endpoints

Ok, me pregunto si la configuración del contenedor afectó al contenedor del cartero. Porque en este punto hemos revertido todas las cosas probables del script mailman.

De acuerdo, durante la noche alcanzó su punto máximo y volvió a bajar un poco. Pero nuestras problemáticas siguen siendo bastante altas, con picos de aproximadamente 20 segundos:

¡Las llamadas de rango de estadísticas están tomando más de 40 segundos!

También están tardando una eternidad en la generación de caché:

¿Podríamos estar viendo un problema con la lectura / escritura de la caché?

@icarito, ¿ podría haber un problema en la lectura / escritura de io o algo en la generación de caché? Simplemente no estoy seguro de por qué tomaría tanto tiempo empaquetar todos los datos en la caché.

Gemas con fugas: marque si estamos bien

• [x] celuloide> 0,16,0, <0,17,2
• [x] csspool <4.0.3
• [x] uva <0,2,5
• [x] oj <2.12.4
• [x] alfombra roja <3.3.3
• [x] redis = 3.3.0
• [x] sidekiq <3.5.1
• [x] estadística-sidekiq
• [x] terubiracer <0,12,2
• [x] zipruby <= 0.3.6

Sin fugas, pero problemas de memoria en cualquier caso:

• [x] activeadmin
• [x] axlsx
• [x] trabajo_retrasado> = 4.06
• [x] libxml-ruby <2.9.0 con Nokogiri RC3
• [x] newrelic_rpm> = 3.9.4, <= 3.9.7
• [x] secuela> = 2.12.0
• [x] pisotón <= 1.3.5

Sigo viendo este tiempo de generación de caché masivo por stats_controller#range y me pregunto si necesitamos ajustar dónde se almacena el caché. Parece que el valor predeterminado es el almacenamiento de archivos (y he comprobado, tenemos los archivos de caché en /plots2/tmp/cache/ . ¿Seríamos ayudó en absoluto por el cambio a la memoria caché en memoria o memcached , ambos de los cuales son aparentemente cambios bastante simples?

https://guides.rubyonrails.org/v3.2/caching_with_rails.html#activesupport -cache-memorystore

También mirando https://www.skylight.io/support/performance-tips

Veré la configuración del correo electrónico ahora, pero si no produce nada, fusionaré esto, desactivando el bucle begin/rescue : # 5840

De acuerdo, nuestro siguiente paso para https://github.com/publiclab/plots2/pull/5841 es desarrollar una estrategia de monitoreo por si el cartero cae.

Implementar con las nuevas credenciales de correo electrónico Y la eliminación begin/rescue . Sin embargo, creo que vale la pena volver a implementarlo con el begin/rescue reinstalado si se resuelve la pérdida de memoria, porque podrían haber sido problemas con las credenciales de correo electrónico.

Último error:

mailman_1 | /app/app/models/comment.rb:265:in add_comment': undefined methodbody' for nil:NilClass (NoMethodError) mailman_1 | from /app/app/models/comment.rb:218:in receive_mail' mailman_1 | from script/mailman_server:31:inblock (2 levels) in <main>' mailman_1 | from /usr/local/bundle/gems/mailman-0.7.0/lib/mailman/router.rb:66:in instance_exec' mailman_1 | from /usr/local/bundle/gems/mailman-0.7.0/lib/mailman/router.rb:66:inroute' mailman_1 | from /usr/local/bundle/gems/mailman-0.7.0/lib/mailman/message_processor.rb:23:in block in process' mailman_1 | from /usr/local/bundle/gems/mailman-0.7.0/lib/mailman/middleware.rb:33:inblock in run' mailman_1 | from /usr/local/bundle/gems/mailman-0.7.0/lib/mailman/middleware.rb:38:in run' mailman_1 | from /usr/local/bundle/gems/mailman-0.7.0/lib/mailman/message_processor.rb:22:inprocess' mailman_1 | from /usr/local/bundle/gems/mailman-0.7.0/lib/mailman/receiver/pop3.rb:43:in block in get_messages' mailman_1 | from /usr/local/lib/ruby/2.4.0/net/pop.rb:666:ineach' mailman_1 | from /usr/local/lib/ruby/2.4.0/net/pop.rb:666:in each_mail' mailman_1 | from /usr/local/bundle/gems/mailman-0.7.0/lib/mailman/receiver/pop3.rb:42:inget_messages' mailman_1 | from /usr/local/bundle/gems/mailman-0.7.0/lib/mailman/application.rb:133:in block in polling_loop' mailman_1 | from /usr/local/bundle/gems/mailman-0.7.0/lib/mailman/application.rb:130:inloop' mailman_1 | from /usr/local/bundle/gems/mailman-0.7.0/lib/mailman/application.rb:130:in polling_loop' mailman_1 | from /usr/local/bundle/gems/mailman-0.7.0/lib/mailman/application.rb:83:inrun' mailman_1 | from /usr/local/bundle/gems/mailman-0.7.0/lib/mailman/application.rb:11:in run' mailman_1 | from script/mailman_server:22:in<main>'

Eso es aqui:

https://github.com/publiclab/plots2/blob/e62bb49e30df79a9ddca5300579b80ff0903e3f4/app/models/comment.rb#L265

¡Arreglado eso! https://github.com/publiclab/plots2/commit/c02b5600fa512108d44b9163f44764a9552bbb73

ug, finalmente publicando relativamente la corrección comment.rb ....

Bien, estamos esperando a ver si la cola de correo electrónico se vacía y vemos que algo vuelve a la normalidad, entonces ...

Dejé un comentario en https://publiclab.org/notes/mimiss/06-04-2019/workshop-viii para probar

Hola @jywarren, le he estado dando una segunda mirada a esto y tengo una teoría.

Primero, aquí hay un gráfico del uso de RAM durante los últimos 3 meses:

¡Es evidente a partir de este gráfico que hemos estado creciendo en el consumo de memoria durante los últimos tres meses!

Regresé un año entero:

Al parecer, en 2019, nuestra aplicación ha aumentado bastante sus requisitos de memoria.

La teoría es que siguiendo la trayectoria de consumo de memoria que hemos estado teniendo, es posible que hayamos alcanzado un umbral en el que hayamos consumido la RAM disponible y hayamos comenzado a depender de Swap, lo que está ralentizando las cosas considerablemente.

El aumento de memoria bien podría ser el tamaño de algunas de nuestras tablas ( rusers estoy mirando). Esto puede tener una relación con # 5524.

Tendremos que implementar algunas optimizaciones, migrar la base de datos a un host diferente o agregar más RAM.

También se recomienda encarecidamente podar la base de datos de usuarios de spam.

Todavía me estoy inclinando hacia el agotamiento de la memoria debido al crecimiento de la aplicación / sitio, que está causando una alta carga de E / S debido a que la memoria de intercambio se "golpea" en el disco.
Revisé nuestro passenger-memory-stats del contenedor web y creo que podemos reducir aún más el grupo de procesos:

Intentaré esto como primer paso para remediar el rendimiento.

Descubrí que en febrero de 2018 habíamos calculado que podíamos ejecutar 11 procesos (porque nuestra aplicación tardaba 500 MB en ejecutarse).
La formula es:

max_app_processes = (TOTAL_RAM * 0.75) / RAM_PER_PROCESS
                  = 6000Mb / 750Mb
                  = 8

pero también estamos ejecutando Skylightd, además de un proceso para obtener comentarios de tweets, además de Sidekick, y también queremos ejecutar el proceso de mailman.
La mayor parte del uso de RAM se encuentra en el contenedor web:

De las dos imágenes anteriores, deduzco que todavía podemos ahorrar un proceso, especialmente si esto hará que las respuestas sean más rápidas.

Pasando a un tamaño de grupo de 4 procesos.

Primera optimización realizada.
¡Prometedores primeros 30 minutos!

¡Oh!

El sábado, 8 de junio de 2019, 8:47 p.m. Sebastian Silva [email protected]
escribió:

Primera optimización realizada.
¡Prometedores primeros 30 minutos!
[imagen: imagen]
https://user-images.githubusercontent.com/199755/59154753-46635b00-8a3f-11e9-87b7-51e660e4a148.png

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6J7GXQIQPVWFTWGYJRLPZR4KJA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVDVREXWG43V2
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAAF6J65RCLAEFO6H6RJLSTPZR4KJANCNFSM4HSA3N3Q
.

Bien, entonces la lista de mitigaciones sería:

• [x] reducir el grupo de procesos
• [] mover la base de datos a la solución de base de datos en la nube de Google
• [] reducir rusers - quizás basándose en el trabajo en https://github.com/publiclab/plots2/issues/5450
• [] cambiar a memcached

Hola @jywarren y @icarito ,

Primero, (y lo digo sin bromear): este hilo resultó ser una lectura bastante buena. Tenía todos los elementos, un misterio, una caza, callejones sin salida, llamadas cercanas, etc.

De todas formas.

Con respecto a la tabla de rusers relativa a # 5450 y # 5524, hubo una agrupación _ enorme _ en rusers que ocurrió entre el 26/4/13 y el 1/1/14.

26/4/2013: 1366934400
1/1/2014: 1388534400
Rango de UID: 59627 - 420114
Usuarios: 360466

¿Quiere probar la primera consulta de la ejecución de prueba que describió en el n. ° 5450 en una parte de ese grupo?

usuarios que no han publicado ningún nodo, comentario, me gusta o suscripción y no han iniciado sesión nunca

Como dijiste, esta sería una consulta fácil, ya que no iniciar sesión nunca cubriría todos los criterios anteriores.

Como referencia sobre el tamaño de porción equivalente a su propuesta de los últimos 6 meses en el otro correo electrónico: En el último mes, hemos marcado ~ 250 publicaciones por primera vez como spam. Entonces, digamos que en los últimos 6 meses tuvimos ~ 1500 usuarios prohibidos debido al spam.

Ah, y supongo que eso trae a colación un buen punto. Si desea deshacerse de los usuarios de spam, puede encontrar todos los usuarios que tienen contenido marcado como spam y luego eliminar los usuarios que los publicaron.

Como se mencionó brevemente en uno de los temas, podría ser bueno que los usuarios con contenido nuevo marcado como spam se eliminen inmediatamente de la base de datos.

Hola @skilfullycurled, ¡ gracias por tu aporte! Entonces, la mayoría de los usuarios son de 2013-2014: eso significa para mí que, si bien puede ayudar a reducir el uso de RAM, en realidad, nuestras tablas principales son rsessions e impresiones .

rsessions supera los 30 GB.
@jywarren y @skilfullycurled : ¡sería genial idear una estrategia para reducir esto y / u optimizar las consultas usando esta tabla!

También creo que Memcached no es una buena opción para este problema, ya que debería consumir más RAM, no menos.

Aunque se puede limitar el uso de memoria de memcached, ¡todavía lo intentaré!

No, de los documentos anteriores:

Si está ejecutando varios procesos de servidor de Ruby on Rails (que es el caso si está utilizando mongrel_cluster o Phusion Passenger), las instancias de proceso del servidor de Rails no podrán compartir datos de caché entre sí. Este almacén de caché no es apropiado para grandes implementaciones de aplicaciones, pero puede funcionar bien para sitios pequeños con poco tráfico con solo un par de procesos de servidor o para entornos de desarrollo y prueba.

Parece que no es demasiado difícil de resolver _rsessions_:
https://stackoverflow.com/questions/10088619/how-to-clear-rails-sessions-table

@jywarren , ¡hagamos esto!

@icarito , no estoy seguro de que esto se haya hecho alguna vez, pero tuve acceso a la base de datos en 2016 y notifiqué a todos que las sesiones de usuario ocupaban más espacio que el resto real de la base de datos. Me dijeron que se eliminarían, por lo que no lo hicieron o el problema sigue siendo que la base de datos continúa manteniendo las sesiones.

Para dar una sensación, a partir de 2016, la base de datos de gráficos _comprimida_ como bz2 era de 1,9 GB (no hay tiempo en este momento para descomprimir para el tamaño real), _ sin comprimir_, con las sesiones eliminadas, era de 518 MB

Gracias @skilfullycurled !!! Creo que recuerdo su entrada de 2016, no sé cómo nos perdimos de borrar eso, pero nuestros volcados de base de datos de hoy tienen más de 8GB comprimidos, probablemente en su mayoría sesiones.
Esperaré la confirmación de @jywarren ; me gustaría ejecutar lo siguiente en producción hoy y luego podemos convertirlo en una tarea de rake o un trabajo cron:

ELIMINAR DE las sesiones DONDE se actualizó_en <FECHA_SUB (AHORA (), INTERVALO 1 DÍA);

Tengo demasiada curiosidad, el archivo sin comprimir es de 6,8 GB menos los 518 MB que nos pone en 6,3 GB. 😆

Las rsessions son en realidad mi conjunto de datos favorito que tengo. Es completamente inútil, pero me encanta que sea tan grande, si no más grande, que los conjuntos de datos que tengo que son útiles. Si alguien tiene alguna idea sobre qué hacer con él, ¡hágamelo saber!

icarito ( @icarito : matrix.org) lo obtuvo de aquí https://stackoverflow.com/questions/10088619/how-to-clear-rails-sessions-table
icarito ( @icarito : matrix.org) debe cerrar cada sesión que 'no ha estado activa en el último día o semana - podemos modificarlo

Solo tomando notas aquí. Suena genial.

Inestable parece llevar mucho tiempo ... puedo intentarlo

BORRAR ... DESDE ... DONDE ... LÍMITE x

Y ejecute tantas veces como sea necesario en producción.

Después de 7 horas, esto todavía está en marcha. Claramente, no es así como queremos hacer esto en producción en un solo lote. Otra cosa es que después de la eliminación, la tabla se fragmentará y el tamaño del archivo no disminuirá para la tabla rsessions . La tabla debe volcarse y volver a crearse para liberar recursos del servidor.

Mi plan para hacer esto es el siguiente:

• [] Tabla de sesiones de volcado de Mysql con where updated_at > DATE_SUB(NOW(), INTERVAL 7 DAY)
• [] Cambiar el nombre de la tabla de sesiones
• [] Cargar datos limpios de la tabla volcada a la nueva tabla de rsessions
• [] Eliminar tabla de rsessions antigua

Intentaré esto en la instancia de prueba stable .

Ok, increíble Sebastian y supongo que esto puede tener efectos positivos.
implicaciones para las mejoras esperadas en el rendimiento de nuestra base de datos después de esto
la mitigación está completa, si incluso vaciar esta tabla puede llevar tanto tiempo ...

El lun, 17 de junio de 2019 a las 9:50 p.m. Sebastian Silva [email protected]
escribió:

Intentaré esto en una instancia de ensayo estable.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6JYXKGLL2V7TV7OMNNDP3A5NVA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXWG43WIMVDF ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAAF6J7KQJ4OXJCRONW5G73P3A5NVANCNFSM4HSA3N3Q
.

Traer a @cesswairimu para que pueda intentar su consulta en el establo nuevamente cuando @icarito haya terminado. Eso debería decirnos si los problemas en # 5917 solo están relacionados con # 5490 (que está solucionado) o si también están relacionados con # 5524.

unstable todavía se está eliminando ...

Dejando algunas notas aquí mientras se realizan pruebas en una instancia estable de ensayo.

• [x] Tabla de sesiones de volcado de Mysql con where updated_at> DATE_SUB (NOW (), INTERVAL 7 DAY)
  
  
  
  • comando: root<strong i="13">@tycho</strong>:/srv/plots_staging/plots2# time docker-compose exec db bash -c "mysqldump --databases plots --tables rsessions --where='updated_at > DATE_SUB(NOW(), INTERVAL 7 DAY)' -h 127.0.0.1 -u plots --password=plots" > /tmp/rsessions.sql
  
  
  • tiempo: 13 s
  
  
• [x] Cambiar el nombre de la tabla de sesiones
  
  
  
  • sintaxis: MariaDB [plots]> rename table rsessions to rsessions_prob
  
  
  • Centinela informa Mysql2::Error: Table 'plots.rsessions' doesn't exist: SELECT rsessions .* FROM rsessions WHER...
  
  
  • la página de inicio va a 500
  
  
• [x] Cargar datos limpios de la tabla volcada a la nueva tabla de sesiones
  
  
  
  • sintaxis: root<strong i="38">@tycho</strong>:/srv/plots_staging/plots2# time cat /tmp/rsessions.sql | docker-comp ose exec -T db bash -c "mysql -h 127.0.0.1 -u plots plots --password=plots"
  
  
  • tiempo: 7 s
  
  
  • crea un nuevo archivo de tabla de rsessions (¡13Mb para la puesta en escena!)
  
  
  • restaura la página de inicio
  
  
• [x] Eliminar tabla de sesiones antiguas:
  
  
  
  • MariaDB [plots]> drop table rsessions_prob; Query OK, 0 rows affected (2.75 sec)
  
  

Probado https://stable.publiclab.org para iniciar sesión.

¡Estoy listo para probar esto en producción!

unstable todavía se

Haciendo operación en la base de datos de producción en vivo:

• [x] Tabla de sesiones de volcado de Mysql con where updated_at> DATE_SUB (NOW (), INTERVAL 7 DAY)
  
  
  
  • tiempo: 48 s
  
  
  • tamaño de descarga: 143Mb
  
  
• [x] Cambiar el nombre de la tabla de sesiones
  
  
  
  • tiempo: 11 s
  
  
  • La página de inicio estuvo inactiva durante 15 minutos a las 6 a.m. UTC
  
  
• [x] Cargar datos limpios de la tabla volcada a la nueva tabla de sesiones
  
  
  
  • crea un nuevo archivo de tabla de rsessions (220Mb)
  
  
  • restaura la página de inicio
  
  
• [x] Eliminar tabla de sesiones antiguas:
  
  
  
  • MariaDB [plots]> drop table rsessions_prob; Query OK, 0 rows affected (43.39 sec)
  
  
  • Liberado ~ 29 GB.
  
  

Probado https://publiclab.org - ¡la sesión se retuvo!
: tada:

mitigación hecha! ¡Ojalá esto nos libere!

Lo dejo para esta noche, el sitio me parece rápido ...: atascado_out_tongue_closed_eyes: ¡espero que sea este!

Bien, entonces la lista de mitigaciones sería:

• [x] reducir el grupo de procesos

• [] mover la base de datos a la solución de base de datos en la nube de Google

• [x] reducir rsessions

• [] cambiar a memcached

Hmm, fue muy rápido esta mañana, ¡pero en general no veo una gran diferencia! 😞

¡Nooooooooooooo! Bueno, solo hay otra explicación y son los fantasmas. Abriré otro número y buscaré encontrar una joya de exorcista o cazafantasmas.

Creo que en realidad ha habido una mejora en el uso de E / S porque usar una tabla de 30 GB es pesado; si miras de cerca, los picos parecen estar relacionados con Statscontroller ... ¿tal vez podríamos hacer que las estadísticas funcionen en la puesta en escena? ¿Puedo hacer que copie la base de datos de producción regularmente, digamos semanalmente?

Hola @icarito , me preguntaba si podrías responder algunas preguntas "educativas" para mí:

si miras de cerca, los picos parecen estar relacionados con Statscontroller ...

¿Por qué sería esto? ¿Debido al almacenamiento en caché? Solo puedo pensar en tres personas que lo usarían y yo soy uno de ellos y no lo he sido.

¿Quizás podríamos hacer que las estadísticas funcionen en la puesta en escena?

He escuchado ... eh ... verte usar mucho la palabra "puesta en escena" últimamente. ¿Qué es eso y cómo influye en el sitio / flujo de trabajo? Si es parte de los documentos, avíseme cuál y primero intentaré entenderlo.

¿Puedo hacer que copie la base de datos de producción regularmente, digamos semanalmente?

Creo que estaría bien. No es tanto que los datos más recientes sean importantes, pero entre el cambio del sistema de preguntas y respuestas y la reciente migración de etiquetas, supongo que semanalmente es una buena idea, ya que detectará cualquier cambio estructural a medida que se presenten. @Cesswairimu , ¿qué te parece ?

Este fue un hilo realmente increíble para leer. Sí, es una gran idea tener las estadísticas en el escenario y copiar semanalmente también está bien: +1:
He tenido esta idea en el futuro de convertir las consultas de estadísticas en un script que crea una vista sql y se elimina y recrea diariamente / o semanalmente por un trabajo y tal vez esto también pueda vivir en el escenario. Me gustaría escuchar sus pensamientos sobre esto y si esto puede ayudar a la pérdida de memoria de alguna manera.

Hola @icarito , ¿podemos aumentar la RAM del servidor? ¿Quizás eso ayude a acelerar el sitio web hasta que mejoremos nuestra tasa de respuesta a las consultas?

¡Gracias!

¡Gracias por tus respuestas! ¡Estoy agradecido por el trabajo que está haciendo y por responder a este problema y leer nuestros esfuerzos! ¡No quiero sonar acusador ni nada! Solo estoy mirando los datos y tratando de mejorar la confiabilidad de nuestro sitio.
Por ejemplo, obtuvimos un pico esta mañana: https://www.skylight.io/app/applications/GZDPChmcfm1Q/1560920940/5m/endpoints

También vemos picos todas las noches (6 a.m. UTC) en la copia de seguridad durante un par de horas.

En cuanto a puesta en escena y producción, actualmente contamos con tres instancias:

Instancia | URL | Registro de compilación | Espacio de trabajo
----------- | ------- | ------------ | -------------
| inestable | https://unstable.publiclab.org/ | https://jenkins.laboratoriopublico.org/view/Staging/job/Plots-Unstable/ | https://jenkins.laboratoriopublico.org/view/Staging/job/Plots-Unstable/ws/
| estable | https://stable.publiclab.org/ | https://jenkins.laboratoriopublico.org/view/Staging/job/Plots-Stable/ | https://jenkins.laboratoriopublico.org/view/Staging/job/Plots-Stable/ws/
| producción | https://publiclab.org/ | n / a | n / A

Tiene razón en que en cuanto a documentación deberíamos hacer un mejor trabajo al describir este proceso. Actualmente encontré algunos documentos aquí https://github.com/publiclab/plots2/blob/master/doc/TESTING.md#testing -branches pero no está claro en absoluto que estas ramas se construyan cuando empujamos a esas ramas.

Actualmente, la base de datos se actualiza manualmente de vez en cuando, pero debería ser sencillo automatizarla ahora que tenemos volcados de base de datos diarios. ¡Lo configuraré y te haré ping!

Esto no significa que no debamos implementar más soluciones, a continuación, creo que un servidor web con subprocesos (Puma) podría ayudar.

¡Esa es una buena pregunta! Estamos en proceso de trasladar nuestro hosting a
nuevo proveedor y esperábamos implementarlo como un clúster de contenedores en el nuevo
proveedor de hosting.

Dado que la ejecución en contenedores no es inmediatamente trivial (porque nuestra aplicación
contenedor no es inmutable) - una alternativa para comenzar es que podríamos
mueva la base de datos primero para hacer espacio.

No creo que debamos aumentar el uso de nuestro alojamiento en nuestro alojamiento actual.
ya que apenas estamos dentro de nuestra cuota permitida, pero @jywarren puede confirmar?

¡Gracias por tu trabajo!

El 19/06/19 11:23, Gaurav Sachdeva escribió:
>

Hola @icarito https://github.com/icarito , ¿podemos aumentar la RAM de
¿el servidor? Quizás eso ayude a acelerar el sitio web hasta que
mejorar nuestra tasa de respuesta a las consultas?

¡Gracias!

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AABQYS3R6ENGBU4FYJXVNXTP3JMPBA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VWWK3TUL52HS4DFVREXG43VMDMVN5WH7HMDFVREXG43VMDVN5WC
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AABQYS7LYPEKQ4QEANK5PRLP3JMPBANCNFSM4HSA3N3Q .

En realidad, me pregunto si podríamos aumentar temporalmente nuestro ariete en ese contenedor.
hasta que hagamos la mudanza y si ayudaría a corto plazo. Creo que estaremos bien
¡Con ese costo aumentando!

El miércoles 19 de junio de 2019 a las 12:59 p.m. Sebastian Silva [email protected]
escribió:

¡Esa es una buena pregunta! Estamos en proceso de trasladar nuestro hosting a
nuevo proveedor y esperábamos implementarlo como un clúster de contenedores en el nuevo
proveedor de hosting.

Dado que la ejecución en contenedores no es inmediatamente trivial (porque nuestra aplicación
contenedor no es inmutable) - una alternativa para comenzar es que podríamos
mueva la base de datos primero para hacer espacio.

No creo que debamos aumentar el uso de nuestro alojamiento en nuestro alojamiento actual.
ya que apenas estamos dentro de nuestra cuota permitida, pero @jywarren puede confirmar?

¡Gracias por tu trabajo!

El 19/06/19 11:23, Gaurav Sachdeva escribió:
>

Hola @icarito https://github.com/icarito , ¿podemos aumentar la RAM de
¿el servidor? Quizás eso ayude a acelerar el sitio web hasta que
mejorar nuestra tasa de respuesta a las consultas?

¡Gracias!

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
<
https://github.com
,
o silenciar el hilo
<
https://github.com/notifications/unsubscribe-auth/AABQYS7LYPEKQ4QEANK5PRLP3JMPBANCNFSM4HSA3N3Q
.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6J4GPT5S2JYJCMGJWP3P3JQVRA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVDVREXWG43V2
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAAF6J4ERAAUV6JD3HUDZKDP3JQVRANCNFSM4HSA3N3Q
.

Ay, @icarito , no, no, no sentí ninguna acusación, para nada. Leí, "esto es lo que está pasando" y solo estaba diciendo "eso es extraño, ¿por qué estaría haciendo eso si nadie estaba en eso ...?" En la misma línea, no quise dar a entender que la documentación fuera deficiente. Solo que no tenías que explicarlo si había alguno.

Y oye, no es una acusación completamente infundada :) aunque me estoy divirtiendo un poco fingiendo que me han engañado y que he pasado a la clandestinidad y tengo que demostrar mi inocencia, pero ese es otro guión en el que estoy trabajando. .

Afortunadamente, estas acusaciones espeluznantes y sin fundamento; ) en ambas partes se han aclarado y podemos volver al negocio en cuestión.

Pregunta relacionada: ¿Por qué estaría activo el controlador de estadísticas si nadie lo estaba usando o ese es el misterio?

Respecto a la puesta en escena, gracias por la explicación. Para asegurarme de que tengo, está diciendo ...

Intentaré esto en una instancia de ensayo estable.

... intercambiable con decir: "Probaré esto en stable.publiclab.org"?

Para el stable.publiclab.org P - ¡Sí! Y eso se basa en cualquier impulso para
la rama master - ¡espero que te ayude!

El miércoles 19 de junio de 2019 a las 3:19 p.m. Benjamin Sugar [email protected]
escribió:

Ay, @icarito https://github.com/icarito , no, no, no sentí nada
acusación, en absoluto. Leí "esto es lo que está pasando" y estaba
diciendo "eso es extraño, ¿por qué estaría haciendo eso si nadie estaba en eso ...?"
En la misma línea, no quise dar a entender que la documentación fuera deficiente.
Solo que no tenías que explicarlo si había alguno.

Y oye, no es una acusación totalmente infundada :) aunque soy
divirtiéndome un poco fingiendo que me han incriminado y me he ido
bajo tierra y tengo que demostrar mi inocencia, pero eso es otra cosa
guión en el que estoy trabajando.

Afortunadamente, estas acusaciones espeluznantes y sin fundamento; ) en ambos son partes
aclarado y podemos volver al asunto en cuestión.

Pregunta relacionada: ¿Por qué estaría activo el controlador de estadísticas si nadie
usándolo o ese es el misterio?

Respecto a la puesta en escena, gracias por la explicación. Para asegurarme de que tengo
esta diciendo...

Intentaré esto en una instancia de ensayo estable.

... intercambiable con decir: "Probaré esto en stable.publiclab.org"?

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6J23U74QTJEVCLT6FLDP3KBBFA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VWWK3TUL52HS4DFVREXG43VMDVNW9H4DFVREXG43VMDVNW9HDFVREXG43VMDVBW9
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAAF6J2RLJGI3ESQKZARV6DP3KBBFANCNFSM4HSA3N3Q
.

@jywarren , ¡sí! Ahora tengo. ¡Gracias!

¡Gracias por la aclaración @skilfullycurled !
De hecho, es un misterio por qué StatsController está tan activo.

Hace breves momentos tuvimos otro pico que nos tumbó durante unos minutos:

El desencadenante en este caso fue en realidad la búsqueda de texto completo.
Pero se puede ver que incluso en este breve intervalo de tiempo (3 min), StatsController fue llamado 21 veces .

Creo que esto puede estar afectando significativamente nuestro desempeño de referencia. Si no se conoce este uso, ¿quizás los rastreadores están llegando a estos puntos finales? ¿Quizás un archivo robots.txt o algún control de acceso lo solucionaría?

@jywarren gracias por la aclaración, buscaré hacerlo lo antes posible.

En realidad, aquí están los detalles del controlador de estadísticas para el intervalo de tiempo anterior:

¿Vamos a hacer un robots.txt en todas las rutas de estadísticas? Entonces, ¿/ stats * básicamente?

El jueves 20 de junio de 2019 a las 12:21 a. M. Sebastian Silva [email protected]
escribió:

En realidad, aquí están los detalles del controlador de estadísticas para el intervalo de tiempo anterior:
[imagen: imagen]
https://user-images.githubusercontent.com/199755/59818278-d4b1c980-92e8-11e9-9b9e-46900a253bd8.png

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6J7GBBZKJQY6TCZMQE3P3MARXA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVDVREXWG43V ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAAF6J7PGJ5YZZHPLWPIJ73P3MARXANCNFSM4HSA3N3Q
.

OK, lo hice, y también eximí / api / * - ya habíamos bloqueado / stats / range *
pero ahora es todo / stats *

https://github.com/publiclab/plots2/commit/aa93dc3465b0cbaaee41ac7bec5e690437a27f5d

El jueves 20 de junio de 2019 a las 2:45 p.m., Jeffrey Warren

¿Vamos a hacer un robots.txt en todas las rutas de estadísticas? Entonces, ¿/ stats * básicamente?

El jueves 20 de junio de 2019 a las 12:21 a. M. Sebastian Silva [email protected]
escribió:

En realidad, aquí están los detalles del controlador de estadísticas para el intervalo de tiempo anterior:
[imagen: imagen]
https://user-images.githubusercontent.com/199755/59818278-d4b1c980-92e8-11e9-9b9e-46900a253bd8.png

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6J7GBBZKJQY6TCZMQE3P3MARXA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVDVREXWG43V ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAAF6J7PGJ5YZZHPLWPIJ73P3MARXANCNFSM4HSA3N3Q
.

¿Entonces no crees que es el almacenamiento en caché?

El caché se genera por uso, es decir, se genera cuando a) está vencido, Y
b) llega una nueva solicitud. Por lo tanto, algo debe solicitarla
caché para generar ... si puedo resolver un par de problemas no relacionados y fusionar
sus relaciones públicas, comenzaré una nueva publicación a producción esta noche (de lo contrario
mañana) y podemos ver si el archivo robots.txt ayuda en algo.

El jueves 20 de junio de 2019 a las 4:53 p.m. Benjamin Sugar [email protected]
escribió:

¿Entonces no crees que es el almacenamiento en caché?

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6JZ5WFKAP5ZCICW67VLP3PUZBA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXWG43WTZV50
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAAF6J4MBMWM6WIOH6VJCY3P3PUZBANCNFSM4HSA3N3Q
.

statscontroller se llama 5.5 veces por minuto

a través de @icarito - así que en la actualización de esta noche podemos ver si los cambios de robots.txt ayudan con esto.

Hola @jywarren , vi que la confirmación de actualización de robot.txt se cambió a estable hace algunos días. ¿Alguna mejora que notó?

Sí, ¡me encantaría una actualización! No estoy seguro de haber obtenido los datos correctos, pero aquí hay algunas imágenes del tragaluz antes de la confirmación, después de la confirmación y las últimas ~ 24 horas. La línea roja indica cuándo se realizó la confirmación. A primera vista, parece que la respuesta es sí, pero puede que no sea significativa, o podría estar interpretando los datos incorrectamente.

Sí, creo que un análisis completo sería genial. Pero la respuesta corta es que
Hemos reducido casi a la mitad nuestro tiempo medio de respuesta a problemas para todas las solicitudes del sitio.
de 5.5+ a 3 o menos. Realmente es una gran mejora. Era un
combinación de a) casi duplicar la RAM de 8 a 15 GB, b) bloquear un marketing
bot en robots.txt, yc) bloquearlo también en las configuraciones de nginx (creo que por
Rango de direcciones IP). La parte difícil es cuánto fue el bot / stats_controller
parte de esto, porque no queríamos detener la actualización general del sitio.

El momento fue:

1. robots.txt aproximadamente a las 5-6 p.m. ET, creo
2. nginx horas más tarde, después de que no estábamos seguros de la rapidez con la que se ejecutaba robots.txt
   leído o respetado
3. ~ 7 am ET expansión de la memoria del sitio el sábado.

En cualquier caso, lo estamos haciendo muy bien ahora. El promedio de carga es <4 en lugar de ~ 8,
y tenemos 6 en lugar de 4 CPU.

El martes, 25 de junio de 2019 a las 5:32 p.m. Benjamin Sugar [email protected]
escribió:

Sí, ¡me encantaría una actualización! No estoy seguro de haber obtenido los datos correctos, pero aquí tienes
algunas imágenes del tragaluz de antes del compromiso, después del compromiso y el
duran ~ 24 horas. La línea roja indica cuándo se realizó la confirmación. Mira hijo
la superficie como la respuesta es sí, pero puede que no sea significativo, o yo
podría estar interpretando los datos incorrectamente.

[imagen: robots_txt]
https://user-images.githubusercontent.com/950291/60135129-05718300-976f-11e9-8fe7-3ca1c081abe3.png

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6J6ALZMY2QMSC7TZQHDP4KFEXA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVODVREXG43VMTUL52HS4DFVODVREXG43VMZMVA
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAAF6J4E2Z2E47A4T6OWUCDP4KFEXANCNFSM4HSA3N3Q
.

¡Cerrando esto ahora!