Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Est ce que trop de threadPool pénalise l'application
Bonjour, j'ai beaucoup de threadPool que sont en cour exécution.
Ces thread pool sont instanciés au démarrage de l'application donc leurs utilisation n'est pas pénalisé par leurs création.
Par contre au niveau processeur, est ce que le processeur est pénalisé par la gestion multitâches?
Est ce que vous avez une idée?
Merci.
Bonjour.
Je présume que tu veux dire que tu as placé beaucoup d"items dans la file du ThreadPool. Alors, non, ils ne consomment que de la mémoire et n'ont aucune impact sur les performances. Ce qui importe en terme de performances, c'est le nombre réel de threads utilisés et qui est défini par ThreadPool.Get/SetMaxThreads(). L'optimum serait un nombre égal au nombre de coeurs disponibles mais, par défaut, cette valeur est égale à 25 afin de garantir une plus grande souplesse aux consommateurs de la classe(*), au léger détriment des perfs.
La valeur par défaut est acceptable. Si ton scénario le permet toutefois et que tu veux soigner les choses pour le confort de l'utilisateur final, tu peux envisager d'utiliser une valeur égale au nombre de coeurs. Attention, tenter d'assigner une valeur inférieure au nombre de coeurs (ou processeurs ?) lève une exception.
(*) Une appli pourrait utiliser le ThreadPool depuis plusieurs points, certains étant situés dans des biblios dont le développeur final n'aurait pas conscience qu'elles utilisent le ThreadPool. Si ce dév final venait à mettre en fil de très longs traitements, une valeur basse pour MaxThreads empêcherait les traitements mis en file par les biblios de s'exécuter.
Un petit bemol toutefois : il semblerait que les allocations mémoires occasionnent des lock qui ne permettent pas d'utiliser toute la puissance des CPU en multi-core. Sur un bi-core en travaillant en mémoire pure, j'ai jamais pu dépasser 80% de taux d'utilisation CPU dans une applio, quand les thread allouaient de la mémoire pour conserver des résultats détaillés du traitement.Alors, non, ils ne consomment que de la mémoire et n'ont aucune impact sur les performances.
Bonjour,
Merci Pour vos repenses bien déaillées
Avant le lancement de mon traitement : J'ai un nombre max de Threads = 50 dont 50 sont disponibles.Envoyé par DonQuiche
Donc, mon traitement va consommer les 50 Threads.
Ces 50 threads vont être lancés sur une machine BiProcesseur(simple ou dual core)
et on plus il vont gèrer un lock sur une liste partagé pour y insérer leurs résultats. --> Je dois diminuer le nombre de Threads pour éviter cette attente suite au lock.
Sans les threads je mets 2min/ traitement
Avec les Thrads je mets 1min:38sec/traitement
L'utilisation de 50 threads ne m'a pas permis de gagner même la moitié du temps!!
Retrouvez moi sur :
Mon Espace Developpez.com-------------------------------
Si tu veux augmenter les performances:
* Un thread par coeur, sur un bi-coeur, ça veut dire "2". Ici, dans la mesure où on a déjà un thread cerbère et que les threads peuvent passer du temps à attendre le cerbère, le mieux est de tester des valeurs de 1 à 5 threads et voir ce que ça donne.
* Des traitements longs par rapport au temps nécessaire pour passer d'un Workitem à un autre. Cette opération n'est certainement pas gratuite. Au besoin, essaye de regrouper plusieurs opérations en un seul Workitem.
Le ThreadPool n'est pas le coupable. Ce n'est simplement pas une baguette magique, il nécessite d'être compris, comme tout ce qui touche au parallélisme.
@Graffito
Veux-tu dire que la mise en file de nouveaux Workitems a un coût non-négligeable, ou bien que tu as eu un scénario où le passage d'un Workitem à un autre bouffait 20% des perfs (ce qui n'a rien de surprenant si les Workitems sont courts). ?
ca dépend de plein de choses
en théorie sans lock avec 2 threads sur un bicore on devrait se rapprocher de la moitié du temps
un lock ca fait attendre, voir si tu peux utiliser un readerwriterlock/slim à la place qui permet dans certains cas de gagner des perfs
ensuite il faut voir la charge des threads, si tes threads ne font que travailler, avoir plus de threads que de cores ralenti le traitement *
il y a une propriété static quelque part dans le framework pour connaitre le nombre de core logique, qu'il faut alors définir sur le max du threadpool
les scénarios qui autorisent d'avoir jusqu'à des centaines de threads même sur un monocore sont des cas où les threads ne bossent pas à plein temps (.sleep(x), manualresetevent.wait, autrethrad.join etc...)
* : windows a des centaines de threads à faire tourner, c'est chacun leur tour quelques nanosecondes
pour passer d'un thread à un autre, il vide le cache du core, le rempli avec les données du thread suivant
Je pense que je ne peux pas utliser readerwriterlock/slim car je fait toujours le lock pour ecriture (Pas de lecture) et je suis sur le .Net2.0
Oui j'ai plus de traitement que de lock.
//Traitement ......
//Lock(Loker){maliste.Add(resultat);}
Quand le traitement commance, l'utilisation de CPU passe de 1% à 100%!!
Il existe aussi des structures concurrentes lock-free comme ConcurrentBag<T>.
Répondre avec citation
Partager