Home My Page Projects Site Admin
Summary Activity Tracker Lists Docs News SCM

[#20011] general inria forge performance issues

Date:
2016-02-01 15:00
Priority:
3
State:
Closed
Submitted by:
Matthieu Imbert (mimbert)
Assigned to:
Matthieu Imbert (mimbert)
Category:
gênant
Group:
none
Resolution:
Fixed
Summary:
general inria forge performance issues

Detailed description
Since approximately Monday, January 25, 2016, scm.gforge.inria.fr has performances issues which results in failures for users to do source control operations (git/subversion, checkouts, clones, etc.)
There are also some reports of similar issues with the forge web interface of with project webpages.

In particular, at the end of last week, scm.gfroge.inria.fr memory was exhausted, the server was swapping.

The Inria Forge team is dealing with these issues in two ways:

- in emergency (and dumb) mode: we restart some services / reboot some servers when needed

- in analysis mode: we try to understand exactly why this happens and to find appropriate long term solutions.

Our current hypothesis are:
- Brute force or DoS attacks on our servers
- Buggy synchronisation or continuous integration scripts from our users
- Rough synchronisation or continuous integration scripts from our users. Eg. it seems that some continuous integration scripts continuously login on the forge each second for polling. If too much projects do that, it increases the load on the servers. It is easy to switch from polling to events with appropriate scm hooks.
- A normal increase of the load on our servers which results in the need to increase VM resources allocated to them (memory, cpu, etc.)
- A combination of these previous causes.

Message  ↓
Date: 2016-08-09 12:33
Sender: Matthieu Imbert

We made two modifications in April and June (https://scm.gforge.inria.fr/anonscm/gitweb?p=siteadmin/env-dev.git;a=commit;h=334a5537f50b403250edfeadad886ce3fccc3fbd and https://scm.gforge.inria.fr/anonscm/gitweb?p=siteadmin/env-dev.git;a=commit;h=a338287e2e1631550c2849dd4269e15aeb08aa79) which aim at lowering probability of, or completely preventing deadlocks in apache2 due to authentication loops issues.

Since then, we're in monitoring mode, and it seems everything is fine.
We also have completely removed the network filtering based on number of connections per IP address per time unit, as it was causing more problems than it solved.

I have tested a complete checkout (from scratch) of 2 huge svn projects with svn over https protocol. These kind of operations where certain to trigger deadlocks and fail with timeout. Now they complete correctly (one repo contains 26564 files for a total of 867M, the other contains 57207 files, for a total of 7G)

Therefore I think this bug is solved and I close it. You can reopen it if you encounter further issues.

Date: 2016-03-03 10:35
Sender: Vincent Lefèvre

Pour confirmer ce que dit Ioana, j'ai un peu plus d'erreurs de connexion depuis quelques jours, mais à part le problème de hier après-midi, qui a duré environ 15 minutes sans possibilité de connexion, c'est habituellement très temporaire (une ou deux erreurs à la suite, pas plus). Ceci dit, c'est toujours embêtant d'avoir une commande qui échoue, d'autant plus que cela laisse parfois des processus en arrière-plan (bug de svn).

Note: je suis toujours en ssh.

Date: 2016-03-03 10:25
Sender: Vincent Lefèvre

> Vincent Lefèvre: Lorsque ça n'a pas fonctionné (mail du 2016-03-02 17:07), combien as tu fait de tentatives?

Plusieurs dizaines après la première erreur. Mais les quelques premières erreurs étaient différentes du "Connection refused". Elles indiquaient en fait une connexion interrompue (utilisation via svn).

Date: 2016-03-03 10:05
Sender: Ioana Manolescu

Pour ce que ça vaut: mon collègue raphael_bonaque a les mêmes problèmes en même temps que nous (notamment hier sur factminder/git) et il se connecte par ssh.

Date: 2016-03-03 09:19
Sender: Ioana Manolescu

Bonjour Mathieu,

merci pour ta patience.

Nous n'avons aucune des adresses mentionnées.

Certains de nos projets ont grandi au fil du temps mais tous nos commits/updates sont a. manuels et b. petits (incrémentaux, quelques lignes changés par ici par là, c'est notamment ce que nous faisions sur factminder).

Nous ne sommes pas en Wifi (connexion filaire INRIA sur le site de Saclay, bâtiment Turing), et les connexions à d'autres sites paraissaient aller tout à fait à la vitesse normale.

Nous allons utiliser aussi ta suggestion d'essayer ssh la prochaine fois que https est problématique.

Merci,

Ioana

Date: 2016-03-03 09:11
Sender: Matthieu Imbert

Ioana Manolescu:

Sur les logs d'hier/avant-hier, des connexions des adresses IP suivantes ont été rejetées en raison d'un trop grand nombre de connexions:
- ci-jenkins12.inria.fr
- tipimouss.irisa.fr
- nat-clients.lix.polytechnique.fr
- maths.r-prg.net.univ-paris7.fr
Est-ce que l'une de ces adresses correspond à l'adresse depuis laquelle toi ou tes collaborateurs faisais tes updates/commits?

Sur les logs d'hier/avant-hier, je note aussi que 4 processus ont été tués du fait d'un manque de mémoire hier entre 21h et 22h. A surveiller, mais peut-être faudrait-il augmenter encore la mémoire du serveur. (Il faut noter que de plus en plus d'utilisateurs de la forge stockent des grosses données de type dataset expérimentaux ou résultats expérimentaux sur la forge, ce qui peut donner lieu à des commits / push / checkout trop gros pour la mémoire du serveur. C'est un point que nous allons continuer de surveiller).

Notes aussi que lorsqu'une opération commit/update échoue, cela peut venir d'un problème réseau entre ta machine et la forge, donc ça peut aussi venir d'une mauvaise connexion wifi (si tu es en wifi), d'une contention réseau transitoire sur le site où tu es hébergée, d'un problème sur renater, etc. Est-ce que l'une de ces causes te parait plausible? (Je ne dis pas que le problème ne vient pas de la forge mais j'essaye de débugguer objectivement le problème)

Date: 2016-03-03 08:39
Sender: Ioana Manolescu

Bonjour,

1. Samedi la forge est tombée, j'avais fait un ticket.

2. Hier il a été impossible de se connecter par git au projet factminder, cela a été on and off tout l'après midi; on s'est envoyé des fichiers par mail pour se synchroniser (!)

C'est cela que j'appelle dégradation de l'environnement de travail.

On a eu aussi des commits qui pour 3 lignes de latex changées, passent une minute. (Mais ci-dessus quand je dis qu'on ne pouvait pas s'en servir, je parle des cas qui finissaient avec un message d'erreur, typiquement SSL handshake failed, dans le même shell où cela avait marché juste avant...)

J'utilise GForge depuis 2003, et le niveau de disponibilité (que je mesure comme "quelle est la probabilité que ça marche, quand j'essaie de faire un update ou un commit à la main") a baissé drastiquement en 2016.

Date: 2016-03-03 08:31
Sender: Matthieu Imbert

Vincent Lefèvre: Lorsque ça n'a pas fonctionné (mail du 2016-03-02 17:07), combien as tu fait de tentatives?

Ioana Manolescu: Peux-tu préciser (qualitativement / quantitativement) ce que tu entend par "mais _ce n'est pas stable_ ni vraiment utilisable. On ne compte plus les erreurs depuis des semaines, en particulier depuis hier, et cela va et revient toutes les quelques heures."

Et pour répondre à tes questions:

- nous ne savons pas ce qui a changé depuis le 25 Janvier, car:

- Les problèmes de début février étaient liés (c'est une certitude) au manque de mémoire qui entrainait du swap et donc une dégradation dramatique des perfs du serveur. La mémoire a été augmentée, le seuil critique où le serveur se met à swapper n'est plus atteint. Si il y a de nouveaux problèmes, ce sont donc des problèmes différents. Il se peut par contre que la cause racine de ces 2 types de problèmes soit la même, mais dans ce cas nous ne l'avons pas encore identifiée

- Le serveur ne plante à ma connaissance pas 2 à 10 fois par jour en ce moment, contrairement à ce qui se passait début Février. Je suis également utilisateur de la forge et entouré d'utilisateurs de la forge et autant début Février les problèmes étaient très visibles et très impactants, autant depuis l'augmentation de mémoire je n'ai pas l'impression d'observer des performances si dégradées que ça (mais je peux me tromper). C'est pour cela que ta phrase "NOTRE ENVIRONNEMNET DE TRAVAIL S'EST DEGRADE DE FACON INSUPPORTABLE " me surprend (excepté pour les soucis de début Février, qui ont été corrigés), d'où ma requête pour que tu précise quantitativement / qualitativement les problèmes que tu rencontres.

- Comment faire pour faire remonter tout cela? -> ouvrir des bugs ici. Si le résultat ne te satisfait pas, tu peux bien sûr faire remonter à ta hiérarchie.

Date: 2016-03-02 16:26
Sender: Ioana Manolescu

Bonjour, ça refonctionne mais _ce n'est pas stable_ ni vraiment utilisable. On ne compte plus les erreurs depuis des semaines, en particulier depuis hier, et cela va et revient toutes les quelques heures.

S'il vous plaît, si vous détectez ce qui a changé depuis le 25 janvier, pouvez-vous y mettre fin?

Si certain d'entre nous ont des besoins si intenses que le serveur unique de tout le monde plante 2-10 fois par jour alors que c'était un exemple de "truc qui marche", peut-on imaginer le financement par INRIA et/ou par les équipes concernées d'un autre serveur uniquement pour ce genre de tâches, pour qu'on puisse quand même fonctionner avec des besoins bien plus réduits?

Je serais prêt ç contribuer même de la part de mon équipe (quoique ce n'est pas tout à fait normal) mais:

NOTRE ENVIRONNEMNET DE TRAVAIL S'EST DEGRADE DE FACON INSUPPORTABLE et je n'entends personne dire qu'il sait le réparer.

Comment faire pour faire remonter tout cela?

Merci,

Ioana

Date: 2016-03-02 16:12
Sender: Vincent Lefèvre

Bon, ça refonctionne pour le moment...

Date: 2016-03-02 16:07
Sender: Vincent Lefèvre

Bonjour,

Depuis une de mes machines (140.77.13.48), la connexion ne fonctionne plus.

OpenSSH_7.1p2 Debian-2, OpenSSL 1.0.2g 1 Mar 2016
debug1: Reading configuration data /home/vlefevre/.ssh/config
debug1: /home/vlefevre/.ssh/config line 81: Applying options for gforge
debug1: /home/vlefevre/.ssh/config line 326: Applying options for *
debug1: Control socket "/tmp/ssh-scm.gforge.inria.fr-22-vlefevre" does not exist
debug2: ssh_connect: needpriv 0
debug1: Connecting to scm.gforge.inria.fr [128.93.193.13] port 22.
debug1: connect to address 128.93.193.13 port 22: Connection refused
ssh: connect to host scm.gforge.inria.fr port 22: Connection refused

Date: 2016-02-29 16:49
Sender: Matthieu Imbert

Eric Poiseau: Si
- vous mettez en place une notification de rebuild par hook
- que vous pusher (git) ou commitez (svn) très souvent
- que à chaque commit vous rebuildez uniquement le minimum à builder (donc: la lib sur laquelle il y a eu un commit + les libs / binaires qui en dépendent)
- et que à l'issue de tout cela votre serveur de CI fait toujours 24 connexions par minutes *en moyenne*
alors on verra pour remonter les seuils pour vous permettre de travailler correctement.
Mais je tiens d'abord à être sûr que vous n'avez pas mis en place une config rapide qui surcharge inutilement nos serveurs.
Notes que j'insiste sur le *en moyenne* car justement pour gérer correctement le cas d'un commit qui entraîne beaucoup de rebuild, la limite est de 60 sur une fenêtre de 5 minutes, ce qui autorise des "burst" de 60 connexions en très peu de temps.

Date: 2016-02-29 16:40
Sender: Matthieu Imbert

Eric Poiseau: Pour les hooks le principe est le suivant: ce n'est pas le système de CI qui poll le SCM pour savoir quand un dépôt a été modifié, c'est le SCM qui dit à la CI de venir récuperer les sources.

Pour la mise en oeuvre je te laisse chercher sur le net il y a plein d'infos sur comment faire, par exemple pour git et jenkins: http://kohsuke.org/2011/12/01/polling-must-die-triggering-jenkins-builds-from-a-git-hook/

Plus généralement tu peux faire une recherche avec les mots clefs "hook trigger build <nom du système de CI> <nom du scm: git ou subversion>"

Date: 2016-02-29 16:31
Sender: Eric Poiseau

On ne lance pas des builds toutes les 2.5 secondes, mais on a des builds en cascade. Lorsqu'une librairie est modifiée, les modules qui l'utilisent sont également reconstruits par cascade.
Je ne connais pas le concept de hook, si tu peux nous expliquer, ou nous donner un lien pour nous expliquer comment cela fonctionne.
Merci

Date: 2016-02-29 15:42
Sender: Matthieu Imbert

Cédric Eoche-Duval: Il y a sur la forge un filtrage des connexions empéchant plus de 60 connexions sur une fenêtre glissante de 5 minutes (donc max 12 connexions par minute). En me basant sur les logs depuis ce matin, votre serveur voit une partie de ses tentatives de connexions ignorées car il fait au total en moyenne (et approximativement) 24 tentatives de connexion par minutes.

Lancez-vous réellement un build toutes les 2.5 secondes?

Si le but est de savoir si un update a été fait sur le dépôt git ou svn, il faut utiliser un hook

Date: 2016-02-29 10:45
Sender: Cédric Eoche-Duval

L'IP est 188.165.197.156

Date: 2016-02-29 10:36
Sender: Matthieu Imbert

Cédric Eoche-Duval: Quelle est l'IP de votre serveur d'intégration continue?

Date: 2016-02-29 10:22
Sender: Cédric Eoche-Duval

Bonjour,

Nous rencontrons toujours des difficultés depuis notre serveur d'intégration continue : svn+ssh ne fonctionne plus pour lui depuis plusieurs jours (au moins depuis le 24/02).

ERROR: Failed to check out svn+ssh://scm.gforge.inria.fr/svn/gazelle/Maven/gazelle-atna/trunk
org.tmatesoft.svn.core.SVNException: svn: E210002: There was a problem while connecting to scm.gforge.inria.fr:22

Date: 2016-02-23 08:39
Sender: Vincent Lefèvre

C'est reparti après tué le master.

Date: 2016-02-23 08:34
Sender: Vincent Lefèvre

Bonjour,

gforge n'est à nouveau plus joignable via SSH (pas de problème avec https en anonymous).

Date: 2016-02-05 10:27
Sender: Eric Poiseau

Non ce n'est pas automatique dans Intellij. Je demande manuellement de mettre à jour le projet

Date: 2016-02-05 10:00
Sender: Matthieu Imbert

Eric: quand tu dis automatique dans Intellij Idea, tu veux dire des updates déclenchés manuellement via une intégration de svn dans Intellij Idea, ou alors une feature de Intellij Idea qui fait automatiquement des svn updates régulièrement dans Intellij Idea?

Date: 2016-02-05 09:56
Sender: Vincent Lefèvre

Pour ma part, $SVN_SSH est le nom d'un wrapper ssh qui teste l'existence du fichier du ControlPath et si ce fichier n'existe pas, il fait un "ssh -fMN scm.gforge.inria.fr" pour lancer le master en arrière-plan; puis il exécute ssh "$@". Cependant, ma config a plus de 10 ans, et je pense que maintenant l'option ControlPersist (qui est assez récente) doit rendre ma solution inutile en combinaison avec "ControlMaster auto", comme utilisé sur le lien indiqué.

Date: 2016-02-05 09:51
Sender: Eric Poiseau

Automatique dans Intellij Idea

Date: 2016-02-05 09:48
Sender: Matthieu Imbert

Eric: il s'agit de svn update automatiques ou manuels?

Date: 2016-02-05 09:44
Sender: Eric Poiseau

Merci Vincent pour le conseil sur le connexion sharing pour SSH. On a applique ce que le lien suivant : https://puppetlabs.com/blog/speed-up-ssh-by-reusing-connections propose et effectivement ca aide pour le ssh.
Mathieu pour les updates, j'entends la commande : svn update

Date: 2016-02-05 09:38
Sender: Matthieu Imbert

Eric: qu'entend-tu par "quand on fait des updates du projet"?
Des updates de type git push / git pull?
ou des updates via ssh/scp/rsync (par exemple de l'espace web de votre projet)?
Ce sont des updates manuels ou automatiques?

Date: 2016-02-05 09:28
Sender: Vincent Lefèvre

Il faut utiliser le connection sharing pour SSH: une seule véritable connexion SSH est faite, et les autres utilisent la connexion maîtresse. En plus, c'est beaucoup plus rapide.

Date: 2016-02-05 09:22
Sender: Eric Poiseau

Tu as raison pour les commits. Cependant quand on fait des updates du projet fait-on une connexion SSH par fichier ? En tout cas avec 7 utilisateurs on est vite bloqué. J'espère qu'une solution sera vite trouvée du coté de la forge

Date: 2016-02-05 09:02
Sender: Ioana Manolescu

Comme quoi, l'usage des uns est le DOS pour autres :)

Euh en fait non. C'est le DOS pour nous tous...

(tout ceci peut être à côté de la plaque bien sûr s'il s'avère que le bug est ailleurs...)

Eric, vous faites plus de 60 commits toutes les 5 minutes, c'est à dire 720 commits par heure?
(Donc en moyenne 5760 commits par jour?)

Date: 2016-02-05 08:58
Sender: Eric Poiseau

Merci Mathieu. Cependant 60 connections SSH pour 5 minutes quand j'ai une équipe de 7 personnes qui travaillent derrière la même adresse ip ... ca ne fait pas beaucoup. Est il possible d'avoir plus pour une adresse ip specifique ? Parce que la c'est le chomage technique. Ils sont aujourd'hui incapables de faire une release.

Date: 2016-02-04 16:53
Sender: Ioana Manolescu

Merci Matthieu pour cela.
Dans l'équipe nous sommes habitués à faire un update "à la main" pas par des scripts rude. J'espère qu'avec les nouvelles mesures on va récupérer notre outil de travail, que dis-je, de survie! :)

Date: 2016-02-04 16:36
Sender: Matthieu Imbert

Current status update:
- We have increased the scm.gforge.inria.fr memory
- We have setup a protection layer against brute force attacks
- On scm.gforge.inria.fr we have limited the number of SSH connections per IP address to 60 on a 5 minutes sliding window, to prevent the server resources to be exhausted by rude scripts from legitimate users.

We are now waiting and checking the outcome of these actions to see if the situation improves.

Date: 2016-02-04 14:53
Sender: Eric Poiseau

Matthieu. Any news on that issue. We are suffering from the issue to perform releases of the project. Thanks for your help

Date: 2016-02-04 10:04
Sender: Matthieu Imbert

other related tickets:
https://support.inria.fr/Ticket/Display.html?id=29030
https://support.inria.fr/Ticket/Display.html?id=29158
https://support.inria.fr/Ticket/Display.html?id=29160
https://support.inria.fr/Ticket/Display.html?id=29164
https://support.inria.fr/Ticket/Display.html?id=29169
https://support.inria.fr/Ticket/Display.html?id=29179

Date: 2016-02-03 10:19
Sender: Ioana Manolescu

C'est encore tombé :( Svp essayez d'obtenir plus de ressources, ça devient handicapant (on ne peut pas travailler!) Que peut-on faire pour vous aider (râler en CP, ?...)

Date: 2016-02-03 10:03
Sender: Vincent Lefèvre

While it was fine yesterday, the SSH connection is freezing again!

Date: 2016-02-02 09:41
Sender: Matthieu Imbert

other related tickets:
https://support.inria.fr/Ticket/Display.html?id=28889
https://support.inria.fr/Ticket/Display.html?id=28891
https://support.inria.fr/Ticket/Display.html?id=28895
https://support.inria.fr/Ticket/Display.html?id=28896

Date: 2016-02-01 16:53
Sender: Vincent Lefèvre

I also got two "E170001: Authorization failed" errors for a svn commit to mpfr (the third try was OK); such a failure is apparently due to insufficient file permissions in the repository, which were temporarily incorrect. I suspect that this may be due to the same issue (if there's still some internal system to correct the permissions after a commit).

Date: 2016-02-01 16:08
Sender: Matthieu Imbert

tickets related:

https://support.inria.fr/Ticket/Display.html?id=28505
https://support.inria.fr/Ticket/Display.html?id=28519
https://support.inria.fr/Ticket/Display.html?id=28308
https://support.inria.fr/Ticket/Display.html?id=28555
https://support.inria.fr/Ticket/Display.html?id=28554
https://support.inria.fr/Ticket/Display.html?id=28552
https://support.inria.fr/Ticket/Display.html?id=28548
http://gforge.inria.fr/tracker/index.php?func=detail&aid=19995&group_id=1&atid=110

Field Old Value Date By
status_idOpen2016-08-10 09:17mimbert
close_dateNone2016-08-10 09:17mimbert
ResolutionNone2016-08-09 12:33mimbert