[OutOfMemoryError] Comment réduire les ressources consommées par une application ?

Bonjour,

j'ai sur une machine disposant de 2go de ram (et apparemment 2go de swap) une appli, qui lorsqu'elle se charge, lance pour 1000 threads et monte la consommation mémoire à 2go. A ce moment là, un outofmemory apparaît, vraisemblablement sur un Thread.start

Existe t-il des restrictions particulières pour la machine virtuelle sur la taille ou le nombre de threads ?J'aurais pensé que windows allouerait ce qu'il faut à la machine virtuelle, quitte à aller swapper...

De même, est-il possible de paramétrer le système pour définir une limite plus haute ?

Merci de vos réponses :)

Je ne connais pas ces limitations mais j'ai juste un petite conseil :

A moins d'être un super calculateur (ce qui m'étonnerait vu la ram), avoir 1000 threads c'est vraiment mauvais coté perf (pas que mémoire mais surtout d'exécution).

En general faut pas faire plus de 2 thread par core sinon le passage d un thread a l'autre devient couteux.

Le mieux est d utiliser un ThreadPool.

Je me doute bien que 1000 est beaucoup trop :/
2 me semble ridiculement bas par contre :/

Lorsqu'on fait un new Thread(), ca ne va pas chercher un thread dans le pool, comme pour timer ?

Citation:

---

Envoyé par Arnard

Je me doute bien que 1000 est beaucoup trop :/
2 me semble ridiculement bas par contre :/

Lorsqu'on fait un new Thread(), ca ne va pas chercher un thread dans le pool, comme pour timer ?

---

2 par core. et ce n'est pas ridicule du tout, un core ne peux en exécuter qu'un seul thread a la fois donc 2 thread par core c'est déjà 2 fois plus que ce que peut exécuter le core. et le fait de passer de l un a l autre coute du temps CPU.

Sinon non instancier un thread c le gérer a la main.

Le threadpool tu lui donne un nombre de thread max (que tu peux calculer avec ton nombre de core) et ensuite tu lui donne des "travaux" a faire et lui s'occupe d distancier ou non des thread.

Y'a tellement peu d'appli multithreadé, et surtout d'OS qui prennent le multithreads (Vista le fait même pas je crois), que 2 threads c'est largement suffisant.

Dans quelles types d'appli aurait-tu besoin de par exemple ne serait-ce que 10 threads ?

Citation:

---

Dans quelles types d'appli aurait-tu besoin de par exemple ne serait-ce que 10 threads ?

---

On peut imaginer une appli web dans lesquelles les utilisateurs lancent des tâches "lourdes" (exemple: simulations qui peuvent durer plusieurs dizaines de minutes). Dans ce cas, l'appli web, répondra par exemple "Votre simulation n° xxx a démarré, pour vérifier l'avancement de vos simulations, cliquez sur ce lien". On ne peut évidement pas dans ce type d'appli prévoir le nombre de thread, puisqu'un nombre indéterminé d'utilisateurs peut lancer un nombre indéterminé de simu.
Toutefois, mêmes dans cette appli, une limitation du nombre de simu simultanées me semblerait judicieuse.

En général ce genre d'appli tournent sur des OS qui gère les multithread non ?

D'ailleurs y'a quoi comme OS qui gère ça comme il faut ?

Citation:

---

Envoyé par Skyounet

Y'a tellement peu d'appli multithreadé, et surtout d'OS qui prennent le multithreads (Vista le fait même pas je crois)

---

ah bon ? comment ça ?
(car j'ai eu l'occasion de tester une application sur un multicore et voir la différence d'utilisation des core en fonction du nombre de threads ...)

Citation:

---

Envoyé par smyley

ah bon ? comment ça ?
(car j'ai eu l'occasion de tester une application sur un multicore et voir la différence d'utilisation des core en fonction du nombre de threads ...)

---

Il me semble, après je dis ptet des grosses conneries, que Vista gère le multithread, mais pas au top.

Genre des applis multithread sur des machines multi processeur (genre Quad Core), ben il sait pas super bien faire.

Si quelqu'un pouvait affirmer ou infirmer, histoire que j'apprenne quelque chose, ce serait cool.

Citation:

---

Envoyé par Graffito

On peut imaginer une appli web dans lesquelles les utilisateurs lancent des tâches "lourdes" (exemple: simulations qui peuvent durer plusieurs dizaines de minutes). Dans ce cas, l'appli web, répondra par exemple "Votre simulation n° xxx a démarré, pour vérifier l'avancement de vos simulations, cliquez sur ce lien". On ne peut évidement pas dans ce type d'appli prévoir le nombre de thread, puisqu'un nombre indéterminé d'utilisateurs peut lancer un nombre indéterminé de simu.
Toutefois, mêmes dans cette appli, une limitation du nombre de simu simultanées me semblerait judicieuse.

---

Bin non le bon plan est pas circonstancier un thread a chaque fois mais de faire une "queue de travail a faire" partagé sur un nombre de thread prédéfini.

Si tu as 50 tache lourde a faire sur un bicore ca ira bien plus vite "sequentiellement" (enfin en queue partagé sur des worker) sur 4 thread qu'en même temps sur 50 thread.

Ce qu'on peut faire tres facilement avec le threadpool ou alors gérer sois même une queue de travail et les thread

Citation:

---

Si tu as 50 tache lourde a faire sur un bicore ca ira bien plus vite "sequentiellement" (enfin en queue partagé sur des worker) sur 4 thread qu'en même temps sur 50 thread.

---

Le traitement séquentiel, effectivement plus performant, sur la somme des durées des tâches ne permet pas un partage équitable du temps entre les taches:
Si l'on ne connait pas à priori la durée d'une tache (imaginons qu'elles puissent varier entre quelques minutes et quelques heures), le problème d'un lancement séquentiel est que des taches courtes devront parfois attendre la fin de tâches longues pour commencer à s'exécuter.

je pense que lorsqu'on arrive a un syteme aussi saturer il faut pas s'amuser a perdre entre 25% et 50% de perf dans l'ordonnancement des threads.

Rien ne t'empeche de faire ta propre Queue avec un système de priorité des traveaux

Salut Anthyme,

Je ne suis pas à l'origine de la discussion.
J'essayais juste de répondre à la question de skyounet:

Citation:

---

Dans quelles types d'appli aurait-tu besoin de par exemple ne serait-ce que 10 threads ?

---

Mon exemple d'appli illustrait le fait qu'avoir un nombre important de thread ne relevait pas forcément d'une mauvaise conception.

Dans l'exemple que je citais, pour limiter le nombre de thread tout en restant équitable avec tous les utilisateurs, il faut refaire son propre multi-tasking, avec en particulier la gestion de temps d'activité et les méthodes de sauvegarde et de reprise dans les tâches.

Citation:

---

Envoyé par Skyounet

Genre des applis multithread sur des machines multi processeur (genre Quad Core), ben il sait pas super bien faire.

---

Ben en fait j'ai eu l'occasion de devoir découper un calcul assez long (mais plusieurs étapes simples à répétition) en plusieurs threads et le calcul est vraiment plus rapide sur un Quad avec 4 threads que sur un Quad avec 2 threads ou sur un Duo avec 2 threads. Par contre pour chaque threads il a tendance à occuper 100 % du CPU donc à la limite 2 threads pour faire des calculs par CPU ça ne sert à rien, vu qu'avec 1 thread on est déjà au max. Donc au final rien ne sert d'avoir 10 threads sur un Quad vu que 4 l'utilisent déjà à 100 % et là c'est empirique.

cette regle du 2*core (que j'ai en fait vue dans un article sur la programation linux) vient du fait que pendant quelques instant un thread peut avoir a faire appel a un IO et donc ne plus occuper un cpu et le 2*core était le rapport qui permetait a la fois de toujours utiliser le processeur au max sans pour autant perdre trop temps a alterner les threads.

Graffito> pas convaincu désolé ;)
pour moi la situation que tu envisage ou un utilisateur serai plus long a servir que d'autre n'est pas une raison suffisant pour gaspiller trop perf dans trop de thread.

Citation:

---

Envoyé par anthyme

cette regle du 2*core (que j'ai en fait vue dans un article sur la programation linux) vient du fait que pendant quelques instant un thread peut avoir a faire appel a un IO et donc ne plus occuper un cpu et le 2*core était le rapport qui permetait a la fois de toujours utiliser le processeur au max sans pour autant perdre trop temps a alterner les threads.

---

Ah oui je n'avais pas pensé aux IO mais maintenant que tu le dit je suis d'accord.