2010-06-22 20 views
2

Bonjour J'ai développé une application de serveur TCP multithread qui permet à 10 connexions simultanées de recevoir des demandes continues de la part de ces dernières, après que certaines demandes de traitement les ont répondu aux clients. Je l'exécute sur une carte basée sur un processeur TI OMAP l137, elle utilise Monta Vista Linux. Les threads sont créés par client soit 10 threads et il est pré-threadé. L'utilisation de la mémoire physique est de l'ordre de% 1.5 et l'utilisation de l'UC est d'environ% 2 selon ps, top et meminfo. Son utilisation vm monte jusqu'à 80M où j'ai 48M (je l'ai réduit de u-boot pour réserver quelques mem pour DSP). Toute aide est appréciée, comment puis-je le réduire ??. (/ Proc/sys/vm/.. astuces ne aide pas :)consommation de mémoire virtuelle de pthreads

Merci.

Répondre

1

Vous pouvez essayer d'utiliser un drop in garbage collecting replacement for malloc(), et voir si cela résoud ton problème. Si c'est le cas, trouvez les fuites et corrigez-les, puis débarrassez-vous du garbage collector.

Il est «intéressant» de suivre ces types de problèmes sur des plates-formes que la plupart des analyseurs de tas et des profileurs (par exemple, valgrind) ne supportent pas complètement (voire pas du tout). Sur une autre note, étant donné les contraintes .. Je suppose que vous avez diminué la taille de la pile de thread par défaut? Je pense que la valeur par défaut est 8M, vous n'avez probablement pas besoin de beaucoup. Voir pthread_attr_setstacksize() si vous ne l'avez pas ajusté.

Modifier:

Vous pouvez vérifier la taille de la pile par défaut avec pthread_attr_getstacksize(). Si elle est à 8M, vous avez déjà soufflé votre plafond pendant la création du fil (10 threads, comme vous l'avez mentionné).

+0

ulimit n'aide pas je vais essayer pthread_attr_setstacksize() Je pense que c'est aux valeurs par défaut, si elle n'est pas définie par la configuration du noyau. – yet

+0

@yet, alors chaque thread a probablement une pile de 4 ou 8 Mo. Vous pouvez vérifier avec pthread_attr_getstacksize() pour voir la valeur par défaut. –

+0

merci! l'utilisation de la mémoire virtuelle est bien maintenant, cela a fonctionné merci. – yet

0

At-il monter à ce niveau et y rester? Ou est-ce que cela finit par manquer de mémoire? Si le premier, vous devez simplement trouver un moyen d'avoir un plus petit ensemble de travail. Si ce dernier, vous avez une fuite de mémoire et devez le réparer.

+0

Il reste là et fonctionne bien pendant une journée, mais après 48 heures, il a été tué par une force magique, dont je n'ai pu trouver aucune idée. dmesg, et les autres logs sont propres le processus est juste terminé. – yet

+0

Je parierais que 'force magique' a été votre fuite de mémoire causant votre application à épuiser son tas. –

+0

merci btw, si c'est tué par OOM-Killer où puis-je trouver les journaux? Comme je l'ai dit, c'est comme une main magique qui l'arrête. (J'ai vérifié les connexions :) – yet

1

La plupart des machines virtuelles sont probablement réservées aux piles. Bien sûr, c'est virtuel, donc il ne se commet pas si vous ne l'utilisez pas.

(je me demande si la taille de la pile par défaut de fil n'a rien à voir avec ulimit -s)

Apparemment oui, selon this other SO question

+0

oui ulimit verboses qu'il est illimité, je l'ai essayé ce matin, il n'a pas aidé, je vais essayer de définir une limitation spécifique au fil. – yet