Memory Leak? #1

New issue

Open

opened 2020-12-06 08:29:36 +00:00 by quentin · 3 comments

quentin commented

2020-12-06 08:29:36 +00:00

Owner

Comprendre pourquoi Guichet part en OOM avec 200Mo de RAM

maximilien commented

2020-12-13 11:37:33 +00:00

Owner

@lx dit que c'est due à la fonction crypto qui gère les invitations :

Ah oui c'est la fonction de hachage qui est utilisée pour gérer les codes d'invitation, elle prend pas mal de RAM en one-shot

@lx dit que c'est due à la fonction crypto qui gère les invitations : > Ah oui c'est la fonction de hachage qui est utilisée pour gérer les codes d'invitation, elle prend pas mal de RAM en one-shot

quentin commented

2020-12-15 11:57:49 +00:00

Author

Owner

(Je l'avais mis sur le mauvais ticket, la fatigue...)

Edit: hints de Alex

C'est la fonction de hachage qui est utilisée pour gérer les codes d'invitation, elle prend pas mal de RAM en one-shot
C'est paramétrable, il faudrait peut-être le baisser

En fait le fait que cette fonction utilise de la RAM c'est une sécurité car ça la rend plus difficilement crackable, c'est relativement important car les codes d'invitation ont peu de chiffres
Et typiquement ça peut être plusieurs centaines de Mo
Mais le trade-off est configurable, tu peux dire plus ou moins de RAM et plus ou moins d'itérations donc de temps CPU
On devrait sans doute mettre moins de RAM et un peu plus de CPU
Sachant que si on fait ça les codes d'invit en attente deviendront invalides, mais peu importe
Et pourquoi elle désaloue pas, c'est sans doute parce qu'on a un GC qui est plutôt flemmard

Pour pas stocker les codes tel quel dans la bdd du ldap.
Ok c'est peut-être overkill mais c'est plus propre.
C'est comme si je stockais le hash d'un mot de passe, mais le mdp a une faible entropie (3 fois 3 digits je crois).
(ou 3 fois 4, je sais plus)
d'où l'intérêt d'une fonction de hashage un peu longue a calculer
et difficile à paralléliser (de par son besoin en ram)

(Je l'avais mis sur le mauvais ticket, la fatigue...) Edit: hints de Alex > C'est la fonction de hachage qui est utilisée pour gérer les codes d'invitation, elle prend pas mal de RAM en one-shot C'est paramétrable, il faudrait peut-être le baisser > En fait le fait que cette fonction utilise de la RAM c'est une sécurité car ça la rend plus difficilement crackable, c'est relativement important car les codes d'invitation ont peu de chiffres Et typiquement ça peut être plusieurs centaines de Mo Mais le trade-off est configurable, tu peux dire plus ou moins de RAM et plus ou moins d'itérations donc de temps CPU On devrait sans doute mettre moins de RAM et un peu plus de CPU Sachant que si on fait ça les codes d'invit en attente deviendront invalides, mais peu importe Et pourquoi elle désaloue pas, c'est sans doute parce qu'on a un GC qui est plutôt flemmard > Pour pas stocker les codes tel quel dans la bdd du ldap. Ok c'est peut-être overkill mais c'est plus propre. C'est comme si je stockais le hash d'un mot de passe, mais le mdp a une faible entropie (3 fois 3 digits je crois). (ou 3 fois 4, je sais plus) d'où l'intérêt d'une fonction de hashage un peu longue a calculer et difficile à paralléliser (de par son besoin en ram)

Armael referenced this issue

2024-11-11 19:07:07 +00:00

invitation codes: tweak argon2 params to consume less memory #70

Armael commented

2024-11-11 19:09:05 +00:00

Owner

Je me suis fait avoir par ce problème aujourd'hui; j'ai soumis une PR: #70 . Je n'ai pas encore vraiment testé, je ne sais pas si l'OOM est si facile que ça à reproduire.

Je me suis fait avoir par ce problème aujourd'hui; j'ai soumis une PR: https://git.deuxfleurs.fr/Deuxfleurs/guichet/pulls/70 . Je n'ai pas encore vraiment testé, je ne sais pas si l'OOM est si facile que ça à reproduire.