<< 5) D'ou sors-tu le "probleme de fuite de memoire liee aux constantes"? C'est un probleme connu (sauf de moi) en Ruby ou je me suis mal exprime? >>
Juste de ton texte que j'ai compris de travers :-) Merci pour le détail pour libxml. Le 31 mars 2015 04:46, "Florian Dutey" <fdu...@gmail.com> a écrit : > Procedons dans l'ordre: > > 1) Je n'ai aucune idee de ce qu'est "la fuite de memoire liee aux > constantes". Ce n'est pas ce que je decrivais precedemment. > Ce que je disais, c'est que libxml-ruby definit la constante XML et que > cela modifie le comportement de beaucoup d'autres bibliotheques, meme si > toi, developpeur, n'utilise jamais libxml directement. > Si tu inclus Oj (parser JSON) dans ton projet, il ne redefinit pas la > constante JSON, ce qui fait que sa presence n'aura aucune incidence (a > priori) sur le reste du code et n'affectera que les endroits ou tu > appelleras explicitement Oj. > > Dans mon cas, libxml etait une dependance d'une autre gem, donc pas une > gem que NOUS avions ajoute nous meme (pour expliquer vaguement que c'etait > un peu cache quoi). Aucune gem autre que la gem incrimine n'utilisait > directement libxml mais le fait que libxml redefinisse la constante XML > impactait d'autres parties du code. > > Il est possible aussi que libxml-ruby ait des consequence sur la > compilation de nokogiri (les 2 gems sont liees historiquement et pour des > raisons de nommages pourraient interferer ensemble). > > 2) Tu as libxml-ruby dans ton projet, debarasse-toi en. Elle n'est plus > maintenue depuis longtemps et le code C est visiblement incompatible avec > le GC pour sur de ruby 2+ (aucune idee pour 1.8 et 1.9). > > Mais d'abord cherche a savoir pourquoi tu en avais besoin a la base. Si > c'est pour nokogiri, ce n'est plus necessaire. Nokogiri embarque son propre > libxml depuis longtemps. Si tu fais du parsing xml "a la mano", alors il > existe d'autres gems tres sympa pour ca. Nokogiri, Ox ... > > 3) Si ton probleme de leak n'est qu'en mode dev, c'est moins critique > qu'en prod. Tu devrais cependant verifier que ta prod est ok. > > 4) Si tu redefinis pleins de constantes a plein d'endroits, et ben... fixe > le probleme et arrete de definir des constantes plusieurs fois :p > > Pour chacune des constantes redefinie, cherche a savoir pourquoi elle > l'est. Si c'est un probleme d'inclusion du meme fichier plusieurs fois, > demmerde toi pour n'inclure le fichier qu'une fois (au demarrage?). > Si c'est necessaire, alors l'utilisation de constantes n'est pas > approprie. > > De maniere generale, les constantes, c'est tres C et Java. Regarde ce que > font les gems pas trop mal construites, en general, elles definissent un > objet de configuration ( > https://github.com/plataformatec/devise/blob/master/lib/devise.rb#L281) > plutot que l'utilisation de constantes qui posent probleme avec la > portabilite du code. > A l'interieur d'un namespace, je preferere les mattr_reader au lieu des > constantes, c'est plus sexy. Mais si tu penses que l'utilisation de > constantes est approprie, fous les dans des namespace et interroge toi de > la raison pour laquelle, au milieu de ton programme, tu ecris un truc du > genre ClassName::CONSTANT = value. > > Si c'est pour changer de maniere temporaire le fonctionnement de quelque > chose, alors tu devrais considerer l'utilisation d'instance, ou de methodes > avec un parametre (et une valeur par defaut pour le cas courant). > > 5) D'ou sors-tu le "probleme de fuite de memoire liee aux constantes"? > C'est un probleme connu (sauf de moi) en Ruby ou je me suis mal exprime? > > Le 30 mars 2015 16:22, Tim <itsumo.sibyl...@gmail.com> a écrit : > >> Salut ! >> Merci pour ton retour. >> >> Je me suis rendu compte en mode dev que j'avais une mega fuite de >> mémoire. (juste à chaque chargement de page....) >> >> J'ai bien lu ton post, je suis en ruby 1.8, rails 2, et j'ai le gem >> libxml-ruby v2.8 dans le gemfile.lock. >> >> Tu parles de constantes redéfinies, mon apply en définie des tonnes à >> plein d'endroit, et je vois pendant les tests le message "warning: already >> initialized constant MA_CONSTANTE" : que faut il éviter pour échapper à la >> fuite de mémoire lié aux constantes ? >> >> Merci. >> >> On Monday, March 30, 2015 at 5:18:59 AM UTC+2, Florian Dutey wrote: >>> >>> Pour ceux que ca interesserait, le probleme a finalement ete resolu: il >>> s'agissait de la bonne vieille gem libxml-ruby qui etait en dependance >>> d'une biblio d'un de nos fournisseurs. >>> J'ai evidemment cree une pull request chez eux pour les avertir de >>> l'obsolescence absolue de cette pourriture. >>> >>> J'en profite donc pour vous passer le message: si vous utilisez encore >>> cette gem dans un de vos projets, essayez de la degager. Elle a la facheuse >>> tendance a (re)definir la constante XML, ce qui fait que l'inclure dans un >>> projet sans l'utiliser aura pour effet d'en faire le defaut pour toute gem >>> qui considereraient que si XML est definie, cela veut dire que vous imposez >>> votre parser (nokogiri par exemple), et donc de spread le probleme a peu >>> pres partout. >>> >>> A plus pour de nouvelles aventures :) >>> >>> Le 19 mars 2015 14:22, Florian Dutey <fdu...@gmail.com> a écrit : >>> >>>> > En fait, je me demandais si c'était le master unicorn ou un de ses >>>> > workers >>>> qui segfaultait >>>> >>>> Clairement le worker, pas le master unicorn. >>>> >>>> Le 19 mars 2015 14:21, Florian Dutey <fdu...@gmail.com> a écrit : >>>> >>>>> > Qu'as tu changé dans tes tests pour les « faire apparaitre » ? >>>>> >>>>> J'ai lance manuellement unicorn pour voir les logs des workers dans >>>>> mon terminal et ne rien louper >>>>> >>>>> > C'est bien le même ruby utilisé dans les deux cas ? Compilé de la même >>>>> façon et sur la même plateforme ? >>>>> >>>>> rvm install 2.2.1. >>>>> Cependant, en local nous sommes sur mac, en prod / staging nous sommes >>>>> sur Docker hoste sur du amazon EC2 (centOS) >>>>> >>>>> > As-tu également du code C dans cette appli ? Cela pourrait être un >>>>> > appel free() ou similaire erroné côté C, qui est appliqué sur un >>>>> autre >>>>> > pointeur que celui souhaité. Ou alors le GC détruit légitimement un >>>>> > objet, mais c'est la fonction qu'on a spécifié pour nettoyer l'objet >>>>> > (si free() ne convient pas) qui fait quelque chose d'incorrect. >>>>> >>>>> Non. Le seul code C provient de gems (sanitize, nokogiri, Oj ...) >>>>> >>>>> > Pas vu non plus d'erreur concernant le GC. Tu as bien vérifié que >>>>> > nul part ton appli (une dépendance ?) ne modifie les paramètres du >>>>> > GC ? Il s'agit bien d'un build ruby « officiel » (pas trop bricolé) >>>>> de >>>>> > ton OS ? >>>>> >>>>> Il s'agit bien d'un build "officiel" de ruby. Je n'ai pas verifie >>>>> qu'aucune gem ne modifie le GC (on a 180 gems, donc bon) >>>>> Normalement, notre appli ne le modifie pas du tout mais c'est une tres >>>>> bonne question et je regarderai >>>>> >>>>> > À défaut de nous montrer le code, nous montrer au moins l'erreur :-) >>>>> >>>>> Je l'ai pas fait a la base parce que les segfault trace, c'est jamais >>>>> interessant, et vraiment, je voulais pas specialement deranger quelqu'un >>>>> en >>>>> mode "aidez moi a debug", plutot "avez vous deja vu ca?". >>>>> >>>>> https://gist.github.com/strikyflo/083ca08885e617d1124a >>>>> https://gist.github.com/strikyflo/00b9f49670c3332b2e94 >>>>> https://gist.github.com/strikyflo/7f2160e078a1651081fd >>>>> >>>>> Ce sont les 3 differentes segfault que j'obtiens (1.7mb chacune) en >>>>> fonction de quand est ce que le GC est passe. >>>>> >>>>> Le modele + controller, reduits a leur minimum en tests font ca: >>>>> https://gist.github.com/strikyflo/6c531a3803eda2367d03 >>>>> >>>>> Il me reste encore a savoir si c'est la vue qui fait tout peter: ya >>>>> beaucoup (beaucoup ...) de haml, donc de nokogiri et cette derniere >>>>> pourrait etre la responsable. >>>>> J'ai fait enormement de tests, donc le fait de ne pas avoir (encore) >>>>> elimine la vue tient au volumes de tests sur les modeles et le controller. >>>>> Et aussi l'enchainement de meetings pour decider des strategies a adopter >>>>> vis a vis de ca (ya d'autres teams et des clients qui sont suspendu a >>>>> cause >>>>> de cette migration). >>>>> >>>>> La decision a ete prise ce matin (heure chinoise) de rollback sur ruby >>>>> 2.0.0 puisque le probleme n'existe pas dans cette version, pour pouvoir >>>>> release quelque chose de stable (toutes les equipes sont en stand by pour >>>>> la nouvelle version de rails depuis 3 semaines, ca complique enormement >>>>> les >>>>> process et les merge de stagner). Donc je vais pas travailler sur le >>>>> probleme dans la semaine qui va suivre. >>>>> Je posais la question surtout pour savoir si quelqu'un avait deja >>>>> experimente un probleme similaire et avait un bon hint a filer (ouais je >>>>> sais, c'est une segfault, donc ca n'arrive jamais en vrai). >>>>> Si je trouve la solution, je n'hesiterai pas a partager par contre, au >>>>> cas ou quelqu'un tombe dessus un jour :) >>>>> >>>>> >>>>> Le 18 mars 2015 19:05, Thibault Jouan <t...@a13.fr> a écrit : >>>>> >>>>> On 2015-03-18 17:02:07 +0800, Florian Dutey wrote: >>>>>> > Apres 1 semaine a ne pas comprendre ces exceptions, a constater le >>>>>> > caractere tres aleatoire de leurs apparitions, j'ai fait le >>>>>> postulat que >>>>>> > c'etait des segfault. Il m'a fallu 2 jours de plus pour les faire >>>>>> > apparaitre. >>>>>> >>>>>> Qu'as tu changé dans tes tests pour les « faire apparaitre » ? >>>>>> D'expérience avec ruby soit tout se passe bien et tu as ton exception >>>>>> écrite sur la sortie d'erreur, avec un code de statut de sortie de 1. >>>>>> Soit en cas de segfault, tu as un rapport d'erreur généré par ruby >>>>>> (sur la sortie d'erreur) différent des cas d'exception, le code de >>>>>> statut de sortie ne sera pas 1, et ton noyau va logger l'erreur. >>>>>> >>>>>> J'imagine que tu ne peux partager le code source responsable de >>>>>> l'erreur, mais as-tu possibilité de nous copier au moins l'erreur ? >>>>>> (éventuellement en « masquant » les chemins si confidentiel). Les >>>>>> backtraces C et ruby devraient aider un minimum. >>>>>> >>>>>> Quel est le code de statut de sortie que tu obtiens, et que log ton >>>>>> noyau dans ce cas ? >>>>>> >>>>>> >>>>>> > Evidemment le probleme est impossible a reproduire en environnement >>>>>> de >>>>>> > developement. Meme en demarrant l'appli avec les parametres de >>>>>> production >>>>>> > en local (ce qui est tres complique de plus a cause des CDN, des >>>>>> serveurs >>>>>> > de cache etc..). >>>>>> > Nous n'avons toujours pas non plus reussi a le reproduire en >>>>>> console, donc >>>>>> > nous avons un protocole assez nul pour reproduire l'erreur (spammer >>>>>> le >>>>>> > serveur sur une action precise). >>>>>> >>>>>> C'est bien le même ruby utilisé dans les deux cas ? Compilé de la >>>>>> même façon et sur la même plateforme ? >>>>>> >>>>>> >>>>>> > J'ai d'un cote, un modele (Page) qui a une propriete "content". Il >>>>>> s'agit >>>>>> > d'un JSON serialize, qui est plutot massif 90% du temps (legacy >>>>>> code). >>>>>> > >>>>>> > Au milieu un controller, qui fait trop de travail >>>>>> > Enfin, plusieurs vues parce qu'on utilise gon + jbuilder et un bon >>>>>> vieux >>>>>> > template haml (legacy, ya un plan pour switcher en SPA avec >>>>>> Rails::API en >>>>>> > backend) >>>>>> > >>>>>> > Regulierement (environ 5% du temps), je me mange une segfault quand >>>>>> > j'essaie d'acceder a la propriete "content" de mon objet Page. La >>>>>> variable >>>>>> > ne contient plus rien, car elle a ete garbage collected, bien >>>>>> qu'etant >>>>>> > toujours referencee pourtant. >>>>>> > Le caractere aleatoire etant quand est ce que GC a ete trigger. Il >>>>>> y a >>>>>> > plusieurs "mauvais endroits" ou il peut etre trigger et cela >>>>>> resulte en des >>>>>> > exceptions differentes (parce qu'on n'accede pas au meme clefs du >>>>>> hash, >>>>>> > mais le principe reste le meme). >>>>>> >>>>>> As-tu également du code C dans cette appli ? Cela pourrait être un >>>>>> appel free() ou similaire erroné côté C, qui est appliqué sur un autre >>>>>> pointeur que celui souhaité. Ou alors le GC détruit légitimement un >>>>>> objet, mais c'est la fonction qu'on a spécifié pour nettoyer l'objet >>>>>> (si free() ne convient pas) qui fait quelque chose d'incorrect. >>>>>> >>>>>> >>>>>> > Avez vous deja vu ce genre de choses? Je n'ai trouve personne qui >>>>>> pleurait >>>>>> > sur google que GC degageait des objets absolument "vivants", alors >>>>>> que j'ai >>>>>> > experimente le probleme 2x en 2 semaines. >>>>>> > Si vous avez deja vu ca, y'a-t-il une raison evidente que je loupe, >>>>>> et/ou >>>>>> > un fix solide? >>>>>> >>>>>> Pas vu non plus d'erreur concernant le GC. Tu as bien vérifié que >>>>>> nul part ton appli (une dépendance ?) ne modifie les paramètres du >>>>>> GC ? Il s'agit bien d'un build ruby « officiel » (pas trop bricolé) de >>>>>> ton OS ? >>>>>> >>>>>> Les derniers soucis de segmentation fault que j'ai vu, c'est soit >>>>>> ça : https://bugs.ruby-lang.org/issues/10685, soit dans 99% des cas >>>>>> mon propre code :P >>>>>> >>>>>> > Je suis aussi preneur de tout conseil qui pourrait m'aider a trouver >>>>>> > l'origine de l'erreur. >>>>>> >>>>>> À défaut de nous montrer le code, nous montrer au moins l'erreur :-) >>>>>> >>>>>> -- >>>>>> Thibault Jouan >>>>>> >>>>> >>>>> >>>> >>> -- >> -- >> Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" >> de Google Groups. >> Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse >> railsfrance@googlegroups.com >> Pour résilier votre abonnement envoyez un e-mail à l'adresse >> railsfrance-unsubscr...@googlegroups.com >> --- >> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes >> "Railsfrance". >> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le >> concernant, envoyez un e-mail à l'adresse >> railsfrance+unsubscr...@googlegroups.com. >> >> Pour obtenir davantage d'options, consultez la page >> https://groups.google.com/d/optout. >> > > -- > -- > Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de > Google Groups. > Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse > railsfrance@googlegroups.com > Pour résilier votre abonnement envoyez un e-mail à l'adresse > railsfrance-unsubscr...@googlegroups.com > --- > Vous recevez ce message, car vous êtes abonné au groupe Google Groupes > "Railsfrance". > Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le > concernant, envoyez un e-mail à l'adresse > railsfrance+unsubscr...@googlegroups.com. > Pour obtenir davantage d'options, consultez la page > https://groups.google.com/d/optout. > -- -- Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups. Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse railsfrance@googlegroups.com Pour résilier votre abonnement envoyez un e-mail à l'adresse railsfrance-unsubscr...@googlegroups.com --- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes Railsfrance. Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse railsfrance+unsubscr...@googlegroups.com. Pour plus d'options, visitez le site https://groups.google.com/d/optout .
