Plots2: Enquête sur les problèmes de mémoire (fuite ?)

Notant le commentaire de @icarito :

Je me demande jywarren parce que j'avais édité docker-compose-production.yml pour utiliser moins de processus (je n'ai pas fait de PR pour cela). Il se pourrait donc que nous ayons simplement fait en sorte que cela s'adapte ainsi.

Et ce graphique :

Nous constatons également de nombreuses erreurs de test SMTP :

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

Oui, la charge est également très élevée. D'après les htop et surtout les iotop il semble que mailman soit assez actif. C'est le coupable c'est sûr ! Avant le 22 mai, nous l'avons exécuté plusieurs fois par jour - si nous pouvions l'exécuter toutes les quelques minutes environ (pas toutes les secondes !) - ce serait 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

Le journal est rempli de cycles de ceux-ci, aucune erreur :

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.

On dirait que Mailman plante et réapparaît immédiatement !

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

J'ai décidé d'arrêter ce conteneur pour ce soir afin de surveiller l'effet sur les performances.

Je pense que nous pouvons également regarder quelles gems updatea ont été fusionnées dans les jours qui ont précédé la publication de ce code. Merci!

C'est tellement bizarre à propos de mailman, je vais regarder la config mais je ne me souviens pas des changements de taux.

Ah tu sais quoi ? Nous l'avons configuré pour réessayer 3 fois. Peut-être que ceux-ci se chevauchent maintenant? Il aurait au moins pu augmenter le taux de tentatives puisqu'il réessaye 3 fois pour chaque exécution planifiée.

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

Ok l'a modifié pendant 20 secondes, ce qui devrait signifier au maximum une nouvelle tentative toutes les 5 secondes --

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

Ce sera le même taux qu'avant lorsque nous avons ajouté des tentatives.

OK, maintenant en train de travailler sur l'analyse après quelques heures :

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

L'ensemble a l'air bien. Mais, à y regarder de plus près, le temps de chargement augmente :

En comparant la dernière partie où elle commence à remonter :

au plus tôt juste après le redémarrage :

Et puis à ceci d'il y a quelques semaines avant tous nos ennuis :

Puis finalement juste après que nous ayons commencé à voir des problèmes les 22 et 23 mai :

Globalement, ce n'est pas concluant.

Ressources:

• une liste de gems et de versions à fuite de mémoire : https://github.com/ASoftCo/leaky-gems
• https://samsaffron.com/archive/2015/03/31/debugging-memory-leaks-in-ruby

L'une des choses difficiles à ce sujet est que c'est juste là où ces deux commits se sont produits :

1. désactivation de la mise en cache sur les profils (que nous avons ensuite annulée) : https://github.com/publiclab/plots2/commit/794df370264a605935483aa8d0e4946bfd14c37c
2. le changement de processus de construction du conteneur : https://github.com/publiclab/plots2/commit/794df370264a605935483aa8d0e4946bfd14c37c

J'aimerais penser que cela est lié à l'ajout du code retry 3 times dans https://github.com/publiclab/plots2/commit/2bc7b498ef3a05bc090ef26f316a30ec0104bcc6 , que j'ai essayé de peaufiner aujourd'hui. Mais en réalité, les temps de chargement augmentent encore lentement.

Cela pourrait signifier que a) quelque chose d'autre le conduit, ou b) le cycle "sauvetage/réessayer" lui-même pourrait provoquer une accumulation de fuite de mémoire?

dois-je commenter entièrement le code de secours/réessayer ?

peut-être que l'attente de mysql pour ramasser prend en fait des threads?

Je vais essayer ça. Le site ne répond presque plus.

J'ai supprimé le retry ici : https://github.com/publiclab/plots2/commit/faa5a12e86bf7944dca43134f649947f03ca96a6

Déployer... ça va prendre du temps.

Hmm ça ne semble vraiment pas résolu... https://oss.skylight.io/app/applications/GZDPChmcfm1Q/1559577660/8h13m/endpoints

Ok, je me demande si la configuration du conteneur a affecté le conteneur mailman? Parce qu'à ce stade, nous avons annulé tous les éléments probables du script mailman.

OK, du jour au lendemain, il a culminé et est redescendu un peu. Mais nos problématiques sont encore assez élevées, avec des pics à environ 20 secondes :

Les appels de plage de statistiques prennent jusqu'à plus de 40 secondes !

Ils prennent également une éternité sur la génération de cache :

Pourrions-nous voir un problème avec la lecture/écriture du cache ?

@icarito pourrait-il y avoir un problème sur l'

Gemmes qui fuient - cochez si tout va bien

• [x] celluloïde > 0,16,0, < 0,17,2
• [x] csspool < 4.0.3
• [x] raisin < 0,2.5
• [x] JO < 2.12.4
• [x] tapis rouge < 3.3.3
• [x] redis = 3.3.0
• [x] acolyte < 3.5.1
• [x] sidekiq-statistique
• [x] le rubyracer < 0,12,2
• [x] zipruby <= 0.3.6

Pas de fuite mais des problèmes de mémoire dans tous les cas :

• [x] administrateur actif
• [x] axlsx
• [x] travail_retardé >= 4,06
• [x] libxml-ruby < 2.9.0 avec Nokogiri RC3
• [x] newrelic_rpm >= 3.9.4, <= 3.9.7
• [x] suite >= 2.12.0
• [x] piétinement <= 1.3.5

Je vois toujours ce temps de génération de cache massif pour stats_controller#range et je me demande si nous devons modifier l'emplacement de stockage du cache. Il semble que la valeur par défaut soit le stockage de fichiers (et j'ai vérifié, nous avons des fichiers de cache dans /plots2/tmp/cache/ . Serions-nous aidés en passant à la mise en cache en mémoire ou à memcached , qui sont tous deux des changements apparemment assez simples?

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

Consultez également https://www.skylight.io/support/performance-tips

Je vais regarder la configuration de la messagerie maintenant, mais si cela ne donne rien, je fusionnerai cela en désactivant la boucle begin/rescue : #5840

OK, notre prochaine étape pour https://github.com/publiclab/plots2/pull/5841 consiste à développer une stratégie de surveillance si mailman tombe en panne.

Déploiement avec les nouvelles informations d'identification de messagerie ET la suppression de begin/rescue . Cependant, je pense que cela vaut la peine d'être redéployé avec le begin/rescue rétabli si la fuite de mémoire est résolue, car il pourrait s'agir de problèmes d'informations d'identification de messagerie.

Dernière erreur :

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>'

C'est ici :

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

Corrigé ça ! https://github.com/publiclab/plots2/commit/c02b5600fa512108d44b9163f44764a9552bbb73

ug, enfin publier le correctif comment.rb...

OK, nous attendons de voir si la file d'attente des e-mails se vide et nous voyons un retour à la normale alors...

J'ai laissé un commentaire sur https://publiclab.org/notes/mimiss/06-04-2019/workshop-viii pour tester

Salut @jywarren J'ai

Voici d'abord un graphique de l'utilisation de la RAM au cours des 3 derniers mois :

Il ressort de ce graphique que nous avons augmenté notre consommation de mémoire au cours des trois derniers mois !

J'y suis retourné une année entière :

Apparemment, en 2019, notre application a considérablement augmenté ses besoins en mémoire.

La théorie est que suivant la trajectoire de consommation de mémoire que nous avons eue, nous avons peut-être atteint un seuil où nous avons consommé de la RAM disponible et avons commencé à compter sur Swap, ce qui ralentit considérablement les choses.

L'augmentation de la mémoire pourrait bien être la taille de certaines de nos tables ( rusers je regarde). Cela peut avoir une relation avec #5524 .

Nous devrons mettre en œuvre quelques optimisations, migrer la base de données vers un autre hôte ou ajouter plus de RAM.

L'élagage de la base de données des utilisateurs de spam est également fortement recommandé.

Je penche toujours vers l'épuisement de la mémoire en raison de la croissance de l'application/du site, ce qui provoque une charge d'E/S élevée en raison de la « déformation » de la mémoire d'échange sur le disque.
J'ai vérifié notre passenger-memory-stats partir du conteneur Web et je pense que nous pouvons encore réduire le pool de processus :

Je vais essayer cela comme un premier pas pour corriger les performances.

J'ai découvert qu'en février 2018, nous avions calculé que nous pouvions exécuter 11 processus (car notre application prenait 500 Mo à exécuter).
La formule est :

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

mais nous exécutons également Skylightd, ainsi qu'un processus de récupération des commentaires de tweet, ainsi que Sidekick, et souhaitons également exécuter le processus mailman.
La majorité de l'utilisation de la RAM se trouve dans le conteneur Web :

À partir des deux images ci-dessus, je déduis que nous pouvons toujours épargner un seul processus, surtout si cela accélère les réponses.

Passage à une taille de pool de 4 processus.

Première optimisation effectuée.
Les 30 premières minutes prometteuses !

Ouh !

Le sam. 8 juin 2019, 20:47 Sebastian Silva [email protected]
a écrit:

Première optimisation effectuée.
Les 30 premières minutes prometteuses !
[image : imagen]
https://user-images.githubusercontent.com/199755/59154753-46635b00-8a3f-11e9-87b7-51e660e4a148.png

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6J7GXQIQPVWFTWGYJRLPZR4KJA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVIC5AQWWLOJKDGO ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAAF6J65RCLAEFO6H6RJLSTPZR4KJANCNFSM4HSA3N3Q
.

OK, donc la liste des atténuations serait :

• [x] réduire le pool de processus
• [ ] déplacer la base de données vers la solution google cloud db
• [ ] réduire rusers - peut-être en s'appuyant sur le travail de https://github.com/publiclab/plots2/issues/5450
• [ ] passer à memcached

Salut @jywarren et @icarito ,

Tout d'abord (et je le dis sans plaisanter) : ce fil s'est avéré être une très bonne lecture. Il y avait tous les éléments, un mystère, une chasse, des impasses, des appels rapprochés, etc.

En tous cas.

En ce qui concerne la table des rusers relative aux #5450 et #5524, il y a un _ énorme _ regroupement de rusers qui s'est produit entre le 26/04/2013 et le 01/01/14.

26/04/2013 : 1366934400
1/1/2014 : 1388534400
Plage d'UID : 59627 - 420114
Utilisateurs : 360466

Voulez-vous essayer la première requête du test que vous avez décrit dans #5450 sur une partie de ce groupe ?

les utilisateurs qui n'ont posté aucun nœud, commentaire, like ou abonnement et ne se sont jamais connectés

Comme vous l'avez dit, ce serait une requête facile car ne jamais se connecter couvrirait tous les critères qui l'ont précédé.

Pour référence sur la taille de portion équivalente à vos 6 derniers mois proposés dans l'autre e-mail : au cours du dernier mois, nous avons marqué environ 250 publications pour la première fois comme spam. Donc, disons qu'au cours des 6 derniers mois, nous avons eu ~1500 utilisateurs bannis en raison de spam.

Oh, et je suppose que cela soulève un bon point. Si vous voulez vous débarrasser des utilisateurs de spam, vous pouvez simplement trouver tous les utilisateurs dont le contenu est marqué comme spam, puis supprimer les utilisateurs qui les ont publiés.

Comme cela a été brièvement évoqué dans l'un des problèmes, il pourrait être bon que les utilisateurs dont le contenu pour la première fois soit marqué comme spam immédiatement supprimé de la base de données.

Salut @skillfullycurled, merci pour ta contribution ! Ainsi, la majorité des utilisateurs date de 2013-2014 : Cela signifie pour moi que même si cela peut aider à réduire l'utilisation de la RAM, en fait, nos principales tables sont les sessions et les impressions .

rsessions est supérieur à 30 Go.
@jywarren et @skilfullycurled - ce serait formidable de proposer une stratégie pour réduire cela et/ou optimiser les requêtes à l'aide de cette table !

De plus, je pense que memcached n'est pas un bon choix pour ce problème car il devrait consommer plus de RAM, pas moins.

Bien que l'on puisse limiter l'utilisation de la mémoire de memcached, je vais quand même l'essayer !

Non, d'après les documents ci-dessus :

Si vous exécutez plusieurs processus serveur Ruby on Rails (ce qui est le cas si vous utilisez mongrel_cluster ou Phusion Passenger), vos instances de processus serveur Rails ne pourront pas partager les données de cache entre elles. Ce magasin de cache n'est pas approprié pour les déploiements d'applications importantes, mais peut bien fonctionner pour les petits sites à faible trafic avec seulement quelques processus serveur ou pour les environnements de développement et de test.

On dirait que ce n'est pas trop difficile à résoudre _rsessions_ :
https://stackoverflow.com/questions/10088619/how-to-clear-rails-sessions-table

@jywarren faisons ça !

@icarito , je ne suis pas sûr que cela ait jamais été fait, mais j'ai eu accès à la base de données en 2016 et j'ai informé tout le monde que les sessions utilisateur prenaient de loin plus d'espace que le reste de la base

Pour donner une idée, à partir de 2016, la base de données des tracés _compressée_ en tant que bz2 était de 1,9 Go (pas le temps pour le moment de décompresser pour la taille réelle), _non compressée_, avec les sessions supprimées, elle était de 518 Mo

Merci @skillfullycurled !!! Je pense que je me souviens de votre contribution de 2016, je ne sais pas comment nous avons manqué de le vider, mais nos vidages de base de données aujourd'hui sont compressés à plus de 8 Go, probablement principalement des sessions.
J'attendrai la confirmation de @jywarren - j'aimerais exécuter ce qui suit en production aujourd'hui, puis nous pourrons en faire une tâche de râteau ou une tâche cron :

DELETE FROM sessions WHERE update_at < DATE_SUB(NOW(), INTERVAL 1 DAY);

Je suis devenu trop curieux, le fichier non compressé fait 6,8 Go donc moins les 518 Mo qui nous placent à 6,3 Go. 😆

Les rsessions sont en fait mon jeu de données préféré que j'ai. C'est complètement use-_less_ , mais j'aime juste qu'il soit aussi grand sinon plus grand que les ensembles de données que j'ai qui sont use-_ful_! Si quelqu'un a une idée de quoi en faire, faites le moi savoir !

icarito ( @icarito :matrix.org) l'a obtenu d'ici https://stackoverflow.com/questions/10088619/how-to-clear-rails-sessions-table
icarito ( @icarito :matrix.org) il devrait se déconnecter de chaque session qui n'a pas été active au cours de la dernière journée ou de la dernière semaine - nous pouvons la modifier

Je prends juste des notes ici. Super.

Unstable semble prendre du temps... je peux essayer

SUPPRIMER ... DE ... O ... LIMITER x

Et exécutez autant de fois que nécessaire en production.

Après 7 heures, la mise en scène est toujours en cours. De toute évidence, ce n'est pas ainsi que nous voulons procéder en production en un seul lot. Une autre chose est qu'après la suppression, la table sera fragmentée et la taille du fichier ne diminuera pas pour la table des rsessions . La table doit être vidé et recréée afin de libérer les ressources du serveur.

Mon plan pour le faire est le suivant :

• [ ] Mysql dump table rsessions avec where updated_at > DATE_SUB(NOW(), INTERVAL 7 DAY)
• [ ] Renommer la table des sessions
• [ ] Charger les données propres de la table dumpée vers la nouvelle table des sessions
• [ ] Supprimer l'ancienne table des sessions

Je vais essayer cela dans l'instance de staging stable .

Ok génial Sebastian et je suppose que cela peut avoir du positif
implications pour les améliorations attendues de nos performances de base de données après cette
l'atténuation est complète, si même le vidage de cette table peut prendre autant de temps...

Le lundi 17 juin 2019, 21:50 Sebastian Silva [email protected]
a écrit:

Je vais essayer cela dans une instance de mise en scène stable.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6JYXKGLL2V7TV7OMNNDP3A5NVA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LN5TEXHJWJKT
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAAF6J7KQJ4OXJCRONW5G73P3A5NVANCNFSM4HSA3N3Q
.

Introduire @cesswairimu pour qu'elle puisse réessayer sa requête sur stable lorsque @icarito aura terminé. Cela devrait nous dire si les problèmes du #5917 ne sont liés qu'au #5490 (qui est corrigé) ou s'ils sont également liés au #5524.

unstable est toujours en cours de suppression...

Laisser quelques notes ici tout en effectuant des tests dans une instance stable de mise en scène.

• [x] Mysql dump table rsessions avec où mis à jour_at > DATE_SUB (NOW(), INTERVAL 7 DAY)
  
  
  
  • commande : 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
  
  
  • temps : 13 s
  
  
• [x] Renommer la table des sessions
  
  
  
  • syntaxe : MariaDB [plots]> rename table rsessions to rsessions_prob
  
  
  • rapports de sentinelle Mysql2::Error: Table 'plots.rsessions' doesn't exist: SELECT rsessions .* FROM rsessions WHER...
  
  
  • la page d'accueil passe à 500
  
  
• [x] Charger les données propres de la table dumpée vers la nouvelle table des sessions
  
  
  
  • syntaxe : 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"
  
  
  • temps : 7 s
  
  
  • crée un nouveau fichier de table de rsessions (13 Mo pour le transfert !)
  
  
  • restaure la page d'accueil
  
  
• [x] Supprimer l'ancienne table des sessions :
  
  
  
  • MariaDB [plots]> drop table rsessions_prob; Query OK, 0 rows affected (2.75 sec)
  
  

Testé https://stable.publiclab.org pour se connecter ..

Je suis prêt à essayer ça en production !

unstable est toujours en cours de suppression...

Faire l'opération sur la base de données de production en direct :

• [x] Mysql dump table rsessions avec où mis à jour_at > DATE_SUB (NOW(), INTERVAL 7 DAY)
  
  
  
  • temps : 48 s
  
  
  • taille du vidage : 143 Mo
  
  
• [x] Renommer la table des sessions
  
  
  
  • temps : 11 s
  
  
  • la page d'accueil était en panne pendant 15 minutes à ~ 6h UTC
  
  
• [x] Charger les données propres de la table dumpée vers la nouvelle table des sessions
  
  
  
  • crée un nouveau fichier de table de rsessions (220Mb)
  
  
  • restaure la page d'accueil
  
  
• [x] Supprimer l'ancienne table des sessions :
  
  
  
  • MariaDB [plots]> drop table rsessions_prob; Query OK, 0 rows affected (43.39 sec)
  
  
  • Libéré ~29 Go.
  
  

Testé https://publiclab.org - la session a été retenue !
:tada:

atténuation faite ! Espérons que cela nous libérera !

je vais le laisser pour ce soir, le site me semble rapide... :stuck_out_tongue_closed_eyes: j'espère que c'est ça !

OK, donc la liste des atténuations serait :

• [x] réduire le pool de processus

• [ ] déplacer la base de données vers la solution google cloud db

• [x] réduire rsessions

• [ ] passer à memcached

Hum, c'était très rapide ce matin, mais dans l'ensemble je ne vois pas une énorme différence ! 😞

Noooooooooooon ! Eh bien, il n'y a qu'une autre explication et ce sont les fantômes. J'ouvrirai un autre problème et chercherai à trouver un joyau d'exorciste ou de chasseur de fantômes.

Je pense qu'en fait, il y a eu une amélioration sur l'utilisation des E/S car l'utilisation d'une table de 30 Go est lourde - si vous regardez de près, les pics semblent liés à Statscontroller... peut-être pourrions-nous faire le travail de statistiques sur la mise en scène ? Je peux lui faire copier la base de données de production régulièrement, par exemple chaque semaine ?

Salut @icarito , je me demandais si tu pouvais répondre à quelques questions "pédagogiques" pour moi :

si vous regardez de près les pics semblent liés à Statscontroller...

Pourquoi serait-ce? A cause de la mise en cache ? Je ne peux penser qu'à trois personnes qui l'utiliseraient et je suis l'une d'entre elles et je ne l'ai pas été.

peut-être pourrions-nous faire le travail des statistiques sur la mise en scène ?

J'ai entendu... euh... vous voir beaucoup utiliser le mot "mise en scène" ces derniers temps. Qu'est-ce que c'est et comment cela s'intègre-t-il dans le site/flux de travail ? Si cela fait partie de la documentation, dites-moi lequel et je tenterai de le comprendre en premier.

Je peux lui faire copier la base de données de production régulièrement, par exemple chaque semaine ?

Je pense que ce serait bien. Ce n'est pas tant que les données les plus récentes sont importantes, mais entre le système de questions-réponses en cours de modification et la récente migration des balises, je suppose que chaque semaine est une bonne idée car elle détectera tous les changements structurels au fur et à mesure qu'ils surviennent.

C'était un fil vraiment génial à lire. Ouais c'est une bonne idée d'avoir les statistiques en scène et de les copier chaque semaine c'est bien aussi :+1:
J'ai eu cette idée à l'avenir de faire des requêtes de statistiques un script qui crée une vue SQL et sa suppression et sa recréation quotidienne / ou hebdomadaire par un travail et peut-être que cela peut également vivre dans l'étape. J'aimerais entendre vos réflexions à ce sujet et si cela peut aider les fuites de mémoire de quelque manière que ce soit.

Hey @icarito , peut-on augmenter la RAM du serveur ? Peut-être que cela aidera à accélérer le site Web jusqu'à ce que nous améliorions notre taux de réponse aux requêtes ?

Merci!

Merci pour vos réponses ! Je vous suis reconnaissant pour le travail que vous faites et pour avoir répondu à ce problème et lu nos efforts ! Je ne veux pas avoir l'air accusateur ou quoi que ce soit ! Je regarde juste les données et j'essaie d'améliorer la fiabilité de notre site.
Par exemple, nous avons eu un pic ce matin : https://www.skylight.io/app/applications/GZDPChmcfm1Q/1560920940/5m/endpoints

Nous voyons également des pics tous les soirs (6h UTC) en sauvegarde pendant quelques heures.

Concernant la mise en scène et la production, nous avons actuellement trois instances :

Instance | URL | Journal de construction | Espace de travail
-----------|-------|-----------|-------------
| instable | https://unstable.publiclab.org/ | https://jenkins.laboratoriopublico.org/view/Staging/job/Plots-Unstable/ | https://jenkins.laboratoriopublico.org/view/Staging/job/Plots-Unstable/ws/
| écurie | https://stable.publiclab.org/ | https://jenkins.laboratoriopublico.org/view/Staging/job/Plots-Stable/ | https://jenkins.laboratoriopublico.org/view/Staging/job/Plots-Stable/ws/
| fabrication | https://publiclab.org/ | n/a | n / A

Vous avez raison, en ce qui concerne la documentation, nous devrions mieux décrire ce processus. Actuellement, j'ai trouvé des documents ici https://github.com/publiclab/plots2/blob/master/doc/TESTING.md#testing -branches mais il n'est pas clair du tout que ces branches se construisent lorsque nous poussons vers ces branches.

La base de données est actuellement mise à jour manuellement de temps en temps, mais il devrait être simple de l'automatiser maintenant que nous avons des vidages de base de données quotidiens. Je vais le configurer et vous envoyer un ping !

Cela ne veut pas dire que nous ne devrions pas implémenter plus de solutions. Ensuite, je pense qu'un serveur Web fileté (Puma) pourrait aider !

Voilà une bonne question! Nous sommes en train de déplacer notre hébergement vers
nouveau fournisseur et espéraient se déployer en tant que cluster de conteneurs dans le nouveau
hébergeur.

Puisque courir dans des conteneurs n'est pas immédiatement anodin (car notre application
conteneur n'est pas immuable) - une alternative pour commencer est que nous pourrions
déplacez d'abord la base de données pour faire de la place.

Je ne pense pas que nous devrions augmenter notre utilisation de l'hébergement dans notre hôte actuel
car nous sommes à peine dans notre quota autorisé, mais @jywarren peut-il confirmer ?

Merci pour votre travail !

Le 19/06/19 11:23, Gaurav Sachdeva a écrit :
>

Hé @icarito https://github.com/icarito , pouvons-nous augmenter la RAM de
le serveur? Cela aidera peut-être à accélérer le site Web jusqu'à ce que nous
améliorer notre taux de réponse aux requêtes ?

Merci!

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AABQYS3R6ENGBU4FYJXVNXTP3JMPBA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMV7NIWW2ZLODNGO-5
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AABQYS7LYPEKQ4QEANK5PRLP3JMPBANCNFSM4HSA3N3Q .

En fait, je me demande si nous pourrions temporairement booster notre bélier dans ce conteneur
jusqu'à ce que nous fassions le déménagement et si cela aiderait à court terme. Je pense que nous serions bien
avec ce coût qui augmente !

Le mer. 19 juin 2019, 12:59 Sebastian Silva [email protected]
a écrit:

Voilà une bonne question! Nous sommes en train de déplacer notre hébergement vers
nouveau fournisseur et espéraient se déployer en tant que cluster de conteneurs dans le nouveau
hébergeur.

Puisque courir dans des conteneurs n'est pas immédiatement anodin (car notre application
conteneur n'est pas immuable) - une alternative pour commencer est que nous pourrions
déplacez d'abord la base de données pour faire de la place.

Je ne pense pas que nous devrions augmenter notre utilisation de l'hébergement dans notre hôte actuel
car nous sommes à peine dans notre quota autorisé, mais @jywarren peut-il confirmer ?

Merci pour votre travail !

Le 19/06/19 11:23, Gaurav Sachdeva a écrit :
>

Hé @icarito https://github.com/icarito , pouvons-nous augmenter la RAM de
le serveur? Cela aidera peut-être à accélérer le site Web jusqu'à ce que nous
améliorer notre taux de réponse aux requêtes ?

Merci!

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
<
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AABQYS3R6ENGBU4FYJXVNXTP3JMPBA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LN55NIXHJLODNG
,
ou couper le fil
<
https://github.com/notifications/unsubscribe-auth/AABQYS7LYPEKQ4QEANK5PRLP3JMPBANCNFSM4HSA3N3Q
.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6J4GPT5S2JYJCMGJWP3P3JQVRA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBJGOKLNMVWXH2P3JQVRA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXH2P
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAAF6J4ERAAUV6JD3HUDZKDP3JQVRANCNFSM4HSA3N3Q
.

Oh, @icarito , non, non, je n'ai ressenti aucune accusation, pas du tout. J'ai lu "c'est ce qui se passe" et je disais juste "c'est étrange, pourquoi ferait-il ça si personne n'était dessus...?" Dans le même ordre d'idées, je ne voulais pas dire que la documentation était médiocre. Seulement que vous n'aviez pas à l'expliquer s'il y en avait.

Et bon, ce n'est pas une accusation totalement infondée : ) même si je m'amuse un peu à prétendre que j'ai été piégé et que je suis entré dans la clandestinité et que je dois prouver mon innocence mais c'est un tout autre scénario sur lequel je travaille .

Heureusement ces accusations sordides et sans fondement ; ) sur les deux parties ont été éclaircies et nous pouvons revenir à l'affaire en cours.

Question connexe : Pourquoi le contrôleur de statistiques serait-il actif si personne ne l'utilisait ou est-ce le mystère ?

Concernant la mise en scène, merci pour l'explication. Pour m'assurer que j'ai, c'est dire...

Je vais essayer cela dans une instance de mise en scène stable.

... interchangeable avec l'expression « Je vais essayer cela sur stable.publiclab.org » ?

Au stable.publiclab.org Q -- oui ! Et c'est construit à partir de toute pression pour
la branche master - j'espère que cela vous aidera !

Le mercredi 19 juin 2019 à 15h19 Benjamin Sugar [email protected]
a écrit:

Oh, @icarito https://github.com/icarito , non, non, je n'en ai pas senti
accusation, pas du tout. J'ai lu, "c'est ce qui se passe" et j'étais juste
en disant "c'est étrange, pourquoi ferait-il ça si personne n'était dessus...?"
Dans le même ordre d'idées, je ne voulais pas dire que la documentation était médiocre.
Seulement que vous n'aviez pas à l'expliquer s'il y en avait.

Et bon, ce n'est pas une accusation totalement infondée : ) bien que je le sois
m'amuser un peu à prétendre que j'ai été encadré et que je suis parti
sous terre et je dois prouver mon innocence mais c'est une tout autre
scénario sur lequel je travaille.

Heureusement ces accusations sordides et sans fondement ; ) sur les deux sont des pièces ont
été éclaircis et nous pouvons revenir à l'affaire en cours.

Question connexe : Pourquoi le contrôleur de statistiques serait-il actif si personne n'était
l'utiliser ou est-ce le mystère?

Concernant la mise en scène, merci pour l'explication. Pour m'assurer que j'ai,
Est en train de dire...

Je vais essayer cela dans une instance de mise en scène stable.

... interchangeable avec l'expression « Je vais essayer cela sur stable.publiclab.org » ?

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6J23U74QTJEVCLT6FLDP3KBBFA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVX5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVX2HJKTDN5
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAAF6J2RLJGI3ESQKZARV6DP3KBBFANCNFSM4HSA3N3Q
.

@jywarren ,

Merci pour la précision @skillfullycurled !
C'est en effet un mystère pourquoi StatsController est si actif ?

Il y a quelques instants, nous avons eu un autre pic qui nous a renversés pendant quelques minutes :

Le déclencheur dans ce cas était en fait la recherche en texte intégral.
Mais on peut voir que même dans cette brève tranche de temps (3 min), StatsController a été appelé 21 fois .

Je pense que cela peut affecter considérablement notre performance de base. Si cette utilisation n'est pas connue, alors peut-être que les robots d'exploration atteignent ces points de terminaison ? Peut-être qu'un fichier robots.txt ou un contrôle d'accès résoudrait le problème ?

@jywarren merci pour la clarification, je vais chercher à le faire dès que possible alors.

En fait, voici les détails de Statscontroller pour la tranche de temps précédente :

Devrions-nous robots.txt toutes les routes de statistiques ? Donc /stats* en gros ?

Le jeu. 20 juin 2019 à 00h21 Sebastian Silva [email protected]
a écrit:

En fait, voici les détails de Statscontroller pour la tranche de temps précédente :
[image : imagen]
https://user-images.githubusercontent.com/199755/59818278-d4b1c980-92e8-11e9-9b9e-46900a253bd8.png

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6J7GBBZKJQY6TCZMQE3P3MARXA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHZPZ3P3MARXA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHZP
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAAF6J7PGJ5YZZHPLWPIJ73P3MARXANCNFSM4HSA3N3Q
.

OK, je l'ai fait, et j'ai également exempté /api/* - nous avions déjà bloqué /stats/range*
mais maintenant c'est tout /stats*

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

Le jeu. 20 juin 2019 à 14 h 45, Jeffrey Warren [email protected] a écrit :

Devrions-nous robots.txt toutes les routes de statistiques ? Donc /stats* en gros ?

Le jeu. 20 juin 2019 à 00h21 Sebastian Silva [email protected]
a écrit:

En fait, voici les détails de Statscontroller pour la tranche de temps précédente :
[image : imagen]
https://user-images.githubusercontent.com/199755/59818278-d4b1c980-92e8-11e9-9b9e-46900a253bd8.png

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6J7GBBZKJQY6TCZMQE3P3MARXA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHZPZ3P3MARXA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHZP
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAAF6J7PGJ5YZZHPLWPIJ73P3MARXANCNFSM4HSA3N3Q
.

Donc tu ne penses pas que c'est la mise en cache ?

Le cache est généré par l'utilisation, c'est-à-dire qu'il est généré lorsque a) il a expiré, ET
b) une nouvelle demande arrive. Donc quelque chose doit la demander pour le
cache à générer... si je peux résoudre quelques problèmes non liés et fusionner
leurs relations publiques, je vais commencer une nouvelle publication en production ce soir (sinon
demain) et nous pouvons voir si le fichier robots.txt est utile ?

Le jeu. 20 juin 2019 à 16h53 Benjamin Sugar [email protected]
a écrit:

Donc tu ne penses pas que c'est la mise en cache ?

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6JZ5WFKAP5ZCICW67VLP3PUZBA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LN5SO4ZWW2ZLODNG85 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAAF6J4MBMWM6WIOH6VJCY3P3PUZBANCNFSM4HSA3N3Q
.

statscontroller est appelé 5,5 fois par minute

via @icarito - donc sur la mise à jour de ce soir, nous pouvons voir si les modifications du

Hé @jywarren , j'ai vu que le commit de mise à jour de robot.txt a été poussé à stable il y a quelques jours. Avez-vous remarqué une amélioration ?

Oui, j'aimerais une mise à jour! Je ne suis pas sûr d'avoir récupéré les données correctes, mais voici quelques images de skylight avant le commit, après le commit et les dernières ~ 24 heures. La ligne rouge indique quand le commit a été effectué. En apparence, la réponse est oui, mais ce n'est peut-être pas significatif, ou j'interprète peut-être les données de manière incorrecte.

Oui, je pense qu'une analyse complète serait géniale. Mais la réponse courte est que
nous avons presque divisé par deux notre temps moyen de réponse aux problèmes pour toutes les demandes de site
de 5,5+ à 3 ou moins. C'est vraiment une énorme amélioration. C'était un
combinaison de a) doublant presque la RAM de 8 à 15 Go, b) bloquant un marketing
bot dans robots.txt, et c) en le bloquant également dans les configurations nginx (je pense par
plage d'adresses IP). La partie difficile est de savoir combien le bot/stats_controller était
en partie, car nous ne voulions pas retarder la mise à niveau globale du site.

Le moment était :

1. robots.txt vers 17h-18h HE, je pense
2. nginx bloque des heures plus tard après que nous ne savions pas à quelle vitesse robots.txt était
   lu ou respecté
3. ~ 7h HE, extension de la mémoire du site samedi.

En tout cas on s'en sort très bien maintenant. La charge moyenne est <4 au lieu de ~8,
et nous avons 6 au lieu de 4 CPU.

Le mar. 25 juin 2019 à 17h32 Benjamin Sugar [email protected]
a écrit:

Oui, j'aimerais une mise à jour! Je ne suis pas sûr d'avoir récupéré les bonnes données, mais voici
quelques images de skylight d'avant le commit, après le commit, et le
dernière ~24 heures. La ligne rouge indique quand le commit a été effectué. Regarde fils
la surface comme la réponse est oui, mais ce n'est peut-être pas significatif, ou je
interprète peut-être les données de manière incorrecte.

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

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6J6ALZMY2QMSC7TZQHDP4KFEXA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVB#W63LNVA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVB#W63LNMVXWWLOJ54
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAAF6J4E2Z2E47A4T6OWUCDP4KFEXANCNFSM4HSA3N3Q
.

Je ferme ça maintenant !