Les contenus de votre forum étant bien sympathiques, je me permet de me taper une petite incrust' pour papoter d'un OS que je découvre avec plaisir (FreeBSD).

La bestiole fonctionne plustot pas mal, et j'avale de la doc en même que je met en exploitation mon petit serveur de jeu.

Mais bon voila, je suis tombé sur un os (sans jeu de mots) et avant d'aller faire un petit post sur une liste de diffusion (core/hack) qui va bien, je préfère vous consulter.

Le contexte : J'utilise mon serveur et FreeBSD pour faire tourner un service de jeu Steam (Valve Software), plus précisément Left4Dead (binaire lancé : srcds_i486). Pour cela, j'utilise donc la compatibilité Abi Linux. La version que j'utilise actuellement est la 7.1-RC1. Après quelques petites configs sur une install de base, le bordel tourne --apparemment-- au poil. Donc je laisse fonctionner le serveur.

Le problème : Au bout de quelque jours, les 6 services lancés en parallèle tombent tous les un après les autres comme des mouches, en laissant en résidu, un gros coredump de plus de 600mo...

Après quelques investigations et un peu de monitoring des services fraîchement relancés, il s'avère que la taille de mémoire de mes binaires se met à enfler, lentement mais sûrement... Je ne peux pourtant pas incriminer le binaire de Valve, car sous Linux ce programme fonctionne nickel et l'espace mémoire occupé est constant (testé sur 3 semaines). Je penche donc pour un problème de fuite de mémoire sur le module de compatibilité Linux. J'ai fais quelques tests en recompilant ce module en statique dans le noyau, mais le résultat est le même.

J'ai bien été voir du coté du source localisé dans /usr/src/sys/i386/linux mais la compréhension de ce code n'est pas à ma portée, et son debuggage encore moins. Mon amis google ne m'a pas été d'une grande aide sur ce coup là (ex : freebsd abi linux memory leak).

Si vous avez des suggestions concernant la résolution de ce type de problème ou si vous avez des adresses de gens à contacter (ou liste de diffusion / forums), je suis preneur !

Peex


Deux top assez informatif :


Code (]last pid:  5830;  load averages:  0.91,  1.00,  0.92  up 0+03:20:32    20:43:52
34 processes:  10 running, 24 sleeping
Mem: 740M Active, 1028M Inact, 138M Wired, 80M Cache, 112M Buf, 8264K Free
Swap: 2048M Total, 2048M Free
 PID USERNAME  THR PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
 734 peex        1  57    0   219M   144M CPU1   1  36:44 20.65% srcds_i486
 762 peex        1   8    0   244M   165M RUN    1  34:47 13.96% srcds_i486
 744 peex        1   8    0   240M   160M RUN    1  30:36 12.89% srcds_i486
 753 peex        1   8    0   259M   173M RUN    1  43:07 10.06% srcds_i486
...
[/code):

[code]last pid: 57104;  load averages:  1.08,  0.89,  0.71  up 0+19:34:23    12:57:43 33 processes:  1 running, 32 sleeping Mem: 1195M Active, 502M Inact, 188M Wired, 97M Cache, 112M Buf, 10M Free Swap: 2048M Total, 124K Used, 2048M Free  PID USERNAME  THR PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND  762 peex        1   8    0   368M   252M nanslp 0 118:50 17.87% srcds_i486  753 peex        1   8    0   406M   275M nanslp 1 176:25 17.58% srcds_i486  744 peex        1   8    0   391M   267M nanslp 1 134:00 13.96% srcds_i486  734 peex        1  44    0   381M   258M select 1 152:32  0.00% srcds_i486 ...

Quote:

un problème de fuite de mémoire sur le module de compatibilité Linux

Sur FreeBSD, la compatibilité Linux est une émulation, pas une distrib., juste ce qu'il faut. On peut d'ailleurs trouver diverses émulations autre que celle par défaut dans /usr/ports/emulators.
Mais il n'est pas dit q'une base Fedora, par exemple, solutionnera.
Après quelques recherches avec l'ami gogole, il semblerait que certains chez Linux aussi aient des problèmes de ballonnements de barrettes mémoires, avec ce binaire... :) .

On trouve surtout des scripts de redémarrage de serveurs (irk~), une option -debug à utiliser en lancant srcds pour obtenir un log, et sur le forum srcds, une solution de mappage mémoire par utilisateur, utilisant tmpfs, dispo également sur FreeBSD.
Solution peut etre plus réfléchie ?.
Les deux cents d'un non joueur :) .

Merci de ton apport. Je n'avais pas vu que certain Linuxiens avaient eux aussi des problèmes de fuite de mémoire, mais ce qui me chagrine, c'est que j'ai choppé les librairies utiles sur mon serveur Linux sur lequel mon service srcds_i486 marche bien. C'est pour cela que j'imaginais un problème axé sur l'émulation. (Je n'utilise pas le pkg/port fc4 de base car la version de la glib diffère.)

Mais bon, je vais commencer par refaire des tests avec d'autres librairies d'autres distrib Linux.

Pour l'idée de redémarrer les services périodiquement pour couper court aux problèmes surcharge mémoire, certe ça marche, mais conceptuellement, ça ne me convient pas :) Niveau qualité de service c'est bof. Cela dit, je te remercie pour ta suggestion, dans certains cas, mieux vaut une rustine que pas de solution du tout.

Mais bon, en même temps, je cherche un peu la petite bête... J'ai une solution qui va bien sous Linux et parfaitement stable, pourquoi aller chercher plus loin ?! Hé bien je suis en plein apprentissage de FreeBSD, et donc je m'amuse un peu :) Et lorsque quelque chose me resiste, je gratte !

Donc si vous avez d'autres suggestions, je suis toujours preneur.

Amicalement,
Peex

Je reviens clôturer ce sujet et vous faire un petit retour d'information sur ce problème.

J'ai continué mes tests pour en arriver à la conclusion que je perds mon temps... :) En effet, je me suis fais berné sur un point et une de mes constatations était fausse.

J'utilise une option assez récente apparue avec le jeux Leaf4Dead : -fork. Avec cette option, le processus parent gère ses descendants. Mais pour une raison que je ne sais pas expliquer, le service de Valve ne réagit pas de la même façon sous Linux et sous FreeBSD. Sous Linux, le processus parent tue à intervalle régulier ses fils, pour en relancer d'autres. Lorsque je lance les processus manuellement (sous Linux), il ne sont donc pas killé et... commencent à gonfler en mémoire, comme sous FreeBSD. Le système d'exploitation n'a donc rien avoir dans cette histoire, c'est bien le binaire de Valve qui est victime d'un memory leak.

Merci à Dumpy qui m'avait donné la bonne réponse dès le début :) Je me suis fait dupé par une rustine à la con... A présent, je sais ce qu'il me reste à faire.

Merci et bonne continuation à tous.
Peex