Arrêt de plans de simulations
Bonjour, je suis entrain de faire tourner des plans de simulations sur 5 ordinateurs : -11520 simus sur celui de Sigrid -4950 sur celui de Youen -8640 sur celui de Steph -11520 sur celui d'EMH -3840 sur Acoustica Les 3 prmeiers plans de simus se sont arrêtés cette nuit, le plan sur EMH tourne sur 7 coeurs sur 10, et celui sur Acoustica continue sans encombre. Pour Sigrid (environ 1760 simus ont tourné), Youen (neviron 1920) et EMH, j'ai les mêmes symptômes : -une fenêtre pop-up "unable to create new native thread" -suivie de ce message : java.lang.OutOfMemoryError: unable to create new native thread at java.lang.Thread.start0(Native Method) at java.lang.Thread.start(Thread.java:717) at java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:957) at java.util.concurrent.ThreadPoolExecutor.processWorkerExit(ThreadPoolExecutor.java:1025) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) Pourtant avec la commande df -h, dans tous les cas, je remarque que la mémoire est loin d'être pleine (ici je travaille sur dev/sda7, il me reste 14G) : Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur udev 16G 0 16G 0% /dev tmpfs 3,2G 9,3M 3,2G 1% /run /dev/sda7 68G 51G 14G 80% / tmpfs 16G 64M 16G 1% /dev/shm tmpfs 5,0M 4,0K 5,0M 1% /run/lock tmpfs 16G 0 16G 0% /sys/fs/cgroup /dev/sda2 100M 9,8M 90M 10% /boot/efi /dev/sda3 725G 450G 276G 63% /media/Windows cgmfs 100K 0 100K 0% /run/cgmanager/fs //nantes/echange 1,6T 1,3T 320G 81% /media/echange //nantes/discard 1,6T 1,3T 320G 81% /media/discard //lorient/echantil 1,2T 727G 474G 61% /media/echantil //lorient/credo 1,2T 727G 474G 61% /media/credo tmpfs 3,2G 52K 3,2G 1% /run/user/1001 /dev/sda8 4,5G 806M 3,5G 19% /media/youyou/34ffe439-1750-4588-bfb5-ff01136b3346 Sur le PC de Steph (environ 1075 simus), je n'ai aucun message d'erreur, mais rien ne tourne, et de même, la mémoire n'est pas pleine. Je ne peux pas faire suivre les debugs, ils font des dizaines de Go. Quel autre paramètre à surveiller pour éviter que ça ne se reproduise? Audric -- Audric Vigier Doctorant à Ifremer, unités EMH (Nantes) et STH/LBH (Brest) E-mail : audric.vigier@ifremer.fr Tel : +33 (0)2 40 37 41 64 (8164)
Le 08/09/2017 à 10:21, Audric Vigier a écrit :
Bonjour,
-suivie de ce message : java.lang.OutOfMemoryError: unable to create new native thread at java.lang.Thread.start0(Native Method) at java.lang.Thread.start(Thread.java:717) at java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:957) at java.util.concurrent.ThreadPoolExecutor.processWorkerExit(ThreadPoolExecutor.java:1025) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748)
Pourtant avec la commande df -h, dans tous les cas, je remarque que la mémoire est loin d'être pleine (ici je travaille sur dev/sda7, il me reste 14G) :
La commande "df" sert à controler l'utilisation de l'espace disque. Ici, c'est la commande "free" qui serait plus utile pour controle la mémoire restante (RAM). Ici, l'erreur "OutOfMemoryError: unable to create new native thread" indique que c'est linux qui refuse de faire tourner plus de simulation en même temps. Combien de RAM ont les PCs ? Parce que 7 simultannées * 1Go (par defaut) ca fait 7Go + le système.
Sur le PC de Steph (environ 1075 simus), je n'ai aucun message d'erreur, mais rien ne tourne, et de même, la mémoire n'est pas pleine.
Il me semble que le PC de steph à 16Go de RAM non ? -- Éric Chatellier - www.codelutin.com - 02.40.50.29.28
Le 08/09/2017 11:26, Eric Chatellier a écrit :
Le 08/09/2017 à 10:21, Audric Vigier a écrit :
Bonjour,
-suivie de ce message : java.lang.OutOfMemoryError: unable to create new native thread at java.lang.Thread.start0(Native Method) at java.lang.Thread.start(Thread.java:717) at java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:957) at java.util.concurrent.ThreadPoolExecutor.processWorkerExit(ThreadPoolExecutor.java:1025) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748)
Pourtant avec la commande df -h, dans tous les cas, je remarque que la mémoire est loin d'être pleine (ici je travaille sur dev/sda7, il me reste 14G) :
La commande "df" sert à controler l'utilisation de l'espace disque. Ici, c'est la commande "free" qui serait plus utile pour controle la mémoire restante (RAM).
Ici, l'erreur "OutOfMemoryError: unable to create new native thread" indique que c'est linux qui refuse de faire tourner plus de simulation en même temps.
Combien de RAM ont les PCs ? Parce que 7 simultannées * 1Go (par defaut) ca fait 7Go + le système.
Sur le PC de Steph (environ 1075 simus), je n'ai aucun message d'erreur, mais rien ne tourne, et de même, la mémoire n'est pas pleine.
Il me semble que le PC de steph à 16Go de RAM non ?
J'ai attaché les sorties de free en PJ pour chacun. -- Audric Vigier Doctorant à Ifremer, unités EMH (Nantes) et STH/LBH (Brest) E-mail : audric.vigier@ifremer.fr Tel : +33 (0)2 40 37 41 64 (8164)
EMH vient de s'arrêter sans message d'erreur, il y avait peu de RAM disponible. En redémarrant ISIS, je suis passé à 34Go disponibles. Sur Acoustica, il y a de moins en moins de RAM disponible, mais toujours autant de simus en // depuis le début, je pense qu'il va bientôt s'arrêter aussi. J'ai besoin de régler ce problème cet après-midi pour relancer mes plans ce soir (Ifremer non accessible le week-end). Est-ce que des ouvertures de fichiers/Context/autres pourraient expliquer ça? Le 08/09/2017 12:01, Audric Vigier a écrit :
Le 08/09/2017 11:26, Eric Chatellier a écrit :
Le 08/09/2017 à 10:21, Audric Vigier a écrit :
Bonjour,
-suivie de ce message : java.lang.OutOfMemoryError: unable to create new native thread at java.lang.Thread.start0(Native Method) at java.lang.Thread.start(Thread.java:717) at java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:957)
at java.util.concurrent.ThreadPoolExecutor.processWorkerExit(ThreadPoolExecutor.java:1025)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Pourtant avec la commande df -h, dans tous les cas, je remarque que la mémoire est loin d'être pleine (ici je travaille sur dev/sda7, il me reste 14G) :
La commande "df" sert à controler l'utilisation de l'espace disque. Ici, c'est la commande "free" qui serait plus utile pour controle la mémoire restante (RAM).
Ici, l'erreur "OutOfMemoryError: unable to create new native thread" indique que c'est linux qui refuse de faire tourner plus de simulation en même temps.
Combien de RAM ont les PCs ? Parce que 7 simultannées * 1Go (par defaut) ca fait 7Go + le système.
Sur le PC de Steph (environ 1075 simus), je n'ai aucun message d'erreur, mais rien ne tourne, et de même, la mémoire n'est pas pleine.
Il me semble que le PC de steph à 16Go de RAM non ?
J'ai attaché les sorties de free en PJ pour chacun.
_______________________________________________ Isis-fish-users mailing list Isis-fish-users@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-users
-- Audric Vigier Doctorant à Ifremer, unités EMH (Nantes) et STH/LBH (Brest) E-mail : audric.vigier@ifremer.fr Tel : +33 (0)2 40 37 41 64 (8164)
En PJ, le résultat de la commande ps aux pour les 5 machines. Le 08/09/2017 13:44, Audric Vigier a écrit :
EMH vient de s'arrêter sans message d'erreur, il y avait peu de RAM disponible. En redémarrant ISIS, je suis passé à 34Go disponibles. Sur Acoustica, il y a de moins en moins de RAM disponible, mais toujours autant de simus en // depuis le début, je pense qu'il va bientôt s'arrêter aussi. J'ai besoin de régler ce problème cet après-midi pour relancer mes plans ce soir (Ifremer non accessible le week-end). Est-ce que des ouvertures de fichiers/Context/autres pourraient expliquer ça?
Le 08/09/2017 12:01, Audric Vigier a écrit :
Le 08/09/2017 11:26, Eric Chatellier a écrit :
Le 08/09/2017 à 10:21, Audric Vigier a écrit :
Bonjour,
-suivie de ce message : java.lang.OutOfMemoryError: unable to create new native thread at java.lang.Thread.start0(Native Method) at java.lang.Thread.start(Thread.java:717) at java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:957)
at java.util.concurrent.ThreadPoolExecutor.processWorkerExit(ThreadPoolExecutor.java:1025)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Pourtant avec la commande df -h, dans tous les cas, je remarque que la mémoire est loin d'être pleine (ici je travaille sur dev/sda7, il me reste 14G) :
La commande "df" sert à controler l'utilisation de l'espace disque. Ici, c'est la commande "free" qui serait plus utile pour controle la mémoire restante (RAM).
Ici, l'erreur "OutOfMemoryError: unable to create new native thread" indique que c'est linux qui refuse de faire tourner plus de simulation en même temps.
Combien de RAM ont les PCs ? Parce que 7 simultannées * 1Go (par defaut) ca fait 7Go + le système.
Sur le PC de Steph (environ 1075 simus), je n'ai aucun message d'erreur, mais rien ne tourne, et de même, la mémoire n'est pas pleine.
Il me semble que le PC de steph à 16Go de RAM non ?
J'ai attaché les sorties de free en PJ pour chacun.
_______________________________________________ Isis-fish-users mailing list Isis-fish-users@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-users
-- Audric Vigier Doctorant à Ifremer, unités EMH (Nantes) et STH/LBH (Brest)
E-mail :audric.vigier@ifremer.fr Tel : +33 (0)2 40 37 41 64 (8164)
_______________________________________________ Isis-fish-users mailing list Isis-fish-users@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-users
-- Audric Vigier Doctorant à Ifremer, unités EMH (Nantes) et STH/LBH (Brest) E-mail : audric.vigier@ifremer.fr Tel : +33 (0)2 40 37 41 64 (8164)
ulimit -a sur Acsoutica en PJ Le 08/09/2017 14:57, Eric Chatellier a écrit :
Le 08/09/2017 à 14:33, Audric Vigier a écrit :
En PJ, le résultat de la commande ps aux pour les 5 machines. Rien la dedans.
Et un "ulimit -a" sur une des machines ?
-- Audric Vigier Doctorant à Ifremer, unités EMH (Nantes) et STH/LBH (Brest) E-mail : audric.vigier@ifremer.fr Tel : +33 (0)2 40 37 41 64 (8164)
Le 08/09/2017 à 15:15, Eric Chatellier a écrit :
Rien non plus. C'est peut etre un probleme avec Isis lui même. Je croyais que c'était un plan d'optimisation. Mais en fait c'est un plan de simulation, le fonctionnement n'a pas changé depuis longtemps. Il faut que j'essaye de le lancer chez moi pour voir, car je n'ai pas specialement de piste...
-- Éric Chatellier - www.codelutin.com - 02.40.50.29.28
Bon du coup je vais relancer mes plans, même s'il est fort probable qu'ils s'arrêtent ce week-end.... Le 08/09/2017 16:15, Eric Chatellier a écrit :
Le 08/09/2017 à 15:15, Eric Chatellier a écrit :
Rien non plus. C'est peut etre un probleme avec Isis lui même. Je croyais que c'était un plan d'optimisation. Mais en fait c'est un plan de simulation, le fonctionnement n'a pas changé depuis longtemps. Il faut que j'essaye de le lancer chez moi pour voir, car je n'ai pas specialement de piste...
-- Audric Vigier Doctorant à Ifremer, unités EMH (Nantes) et STH/LBH (Brest) E-mail : audric.vigier@ifremer.fr Tel : +33 (0)2 40 37 41 64 (8164)
Le 08/09/2017 à 16:20, Audric Vigier a écrit :
Bon du coup je vais relancer mes plans, même s'il est fort probable qu'ils s'arrêtent ce week-end....
Je suis en train de faire tourner un grand nombre de simulation pour voir si je reproduit le problème. Sinon, je suis à l'ifremer demain. Si tu y es aussi, je pourrais peut etre regarder directement sur place. -- Éric Chatellier - www.codelutin.com - 02.40.50.29.28
Je serais là aussi, tu pourras donc observer le problème dans son milieu naturel. Pour info, sur mon PC Windows (4 coeurs), le plan a tourné jusqu'à la fin malgré l'encombrement de C:/ ; sur Acoustica (4 coeurs aussi), qui est sous Linux, au final le plan a tourné sans encombre jusqu'à la fin. Pour les plans que j'ai relancé sur les machines de Sigrid, Steph, Youen et EMH, ils se sont arrêtés avant la fin, en faisant à peu près le même nombre de simus que la dernière fois. Le 2017-09-11 09:33, Eric Chatellier a écrit :
Le 08/09/2017 à 16:20, Audric Vigier a écrit :
Bon du coup je vais relancer mes plans, même s'il est fort probable qu'ils s'arrêtent ce week-end.... Je suis en train de faire tourner un grand nombre de simulation pour voir si je reproduit le problème.
Sinon, je suis à l'ifremer demain. Si tu y es aussi, je pourrais peut etre regarder directement sur place.
-- Audric Vigier Doctorant à Ifremer, unités EMH (Nantes) et STH/LBH (Brest) E-mail : audric.vigier@ifremer.fr Tel : +33 (0)2 40 37 41 64 (8164)
Hello, Autre chose, desfois les plans de simulations appellent en parallèle + de simulations que de coeurs dès le départ (par exemple 12 simus pour 4 coeurs). J'ai eu le cas ce week-end sur mon PC Windows, et ça s'est reproduit ce matin sur la machine Xubuntu de Sigrid, ce qui a provoqué un freeze, puisque toutes les ressources étaient allouées à ISIS. Rien ne tournait du coup. En redémarrant ISIS, puis en relançant le plan, le plan se remet à tourner normalement Le 2017-09-11 09:52, Audric Vigier a écrit :
Je serais là aussi, tu pourras donc observer le problème dans son milieu naturel. Pour info, sur mon PC Windows (4 coeurs), le plan a tourné jusqu'à la fin malgré l'encombrement de C:/ ; sur Acoustica (4 coeurs aussi), qui est sous Linux, au final le plan a tourné sans encombre jusqu'à la fin. Pour les plans que j'ai relancé sur les machines de Sigrid, Steph, Youen et EMH, ils se sont arrêtés avant la fin, en faisant à peu près le même nombre de simus que la dernière fois.
Le 2017-09-11 09:33, Eric Chatellier a écrit : Le 08/09/2017 à 16:20, Audric Vigier a écrit : Bon du coup je vais relancer mes plans, même s'il est fort probable qu'ils s'arrêtent ce week-end....
Je suis en train de faire tourner un grand nombre de simulation pour voir si je reproduit le problème.
Sinon, je suis à l'ifremer demain. Si tu y es aussi, je pourrais peut etre regarder directement sur place.
-- Audric Vigier Doctorant à Ifremer, unités EMH (Nantes) et STH/LBH (Brest) E-mail : audric.vigier@ifremer.fr Tel : +33 (0)2 40 37 41 64 (8164) _______________________________________________ Isis-fish-users mailing list Isis-fish-users@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-users -- Audric Vigier Doctorant à Ifremer, unités EMH (Nantes) et STH/LBH (Brest) E-mail : audric.vigier@ifremer.fr Tel : +33 (0)2 40 37 41 64 (8164)
Le 11/09/2017 à 13:56, Audric Vigier a écrit :
Hello,
Autre chose, desfois les plans de simulations appellent en parallèle + de simulations que de coeurs dès le départ (par exemple 12 simus pour 4 coeurs).
Ha, c'est peut être une piste. Ca expliquerais pourquoi le PC refuse de lancer des simulations ou bout d'un moment. -- Éric Chatellier - www.codelutin.com - 02.40.50.29.28
Le 11/09/2017 à 13:56, Audric Vigier a écrit :
Hello,
Autre chose, desfois les plans de simulations appellent en parallèle + de simulations que de coeurs dès le départ (par exemple 12 simus pour 4 coeurs).
Ha, c'est peut être une piste. Ca expliquerais pourquoi le PC refuse de lancer des simulations ou bout d'un moment. Possible, mais ce n'est pas systématique, j'ai retrouvé des machines
Le 11/09/2017 18:04, Eric Chatellier a écrit : plantées avec moins de simus que de coeurs en cours.
-- Audric Vigier Doctorant à Ifremer, unités EMH (Nantes) et STH/LBH (Brest) E-mail : audric.vigier@ifremer.fr Tel : +33 (0)2 40 37 41 64 (8164)
Le 11/09/2017 à 18:05, Audric Vigier a écrit :
Possible, mais ce n'est pas systématique, j'ai retrouvé des machines plantées avec moins de simus que de coeurs en cours.
Je ne comprend pas pourquoi mais Isis crée plein de thread et ne les libère pas :( On arrive à la limite de la machine en nombre de thread (31196). En attenant de trouver la cause, il est possible d'augmenter la limite avec "ulimit -u 131072" par exemple. -- Éric Chatellier - www.codelutin.com - 02.40.50.29.28
Le 12/09/2017 15:50, Eric Chatellier a écrit :
Le 11/09/2017 à 18:05, Audric Vigier a écrit :
Possible, mais ce n'est pas systématique, j'ai retrouvé des machines plantées avec moins de simus que de coeurs en cours. Je ne comprend pas pourquoi mais Isis crée plein de thread et ne les libère pas :(
On arrive à la limite de la machine en nombre de thread (31196).
En attenant de trouver la cause, il est possible d'augmenter la limite avec "ulimit -u 131072" par exemple. J'ai relancé des plans qui font entre 4000 et 6000 simus sur 4 machines en local, en augmentant la limite comme suggéré. Je me suis basé sur le nombre de simus précédemment effectué et celui que je voulais avec ces nouveaux plans, j'ai multiplié les limites par entre 1.5 et 6 fois en fonction des machines. J'ai ugmenté les limites et lancé ISIS en super utilisateur pour être de bénéficier de cette augmentation. Les machines de Sigrid et Youen ont déjà affiché 2 pop-ups "Unable to create new native thread", après qq centaines de simus. Les plans continuent de tourner, mais j'ai peur de vivre la même mésaventure. A suivre...
-- Audric Vigier Doctorant à Ifremer, unités EMH (Nantes) et STH/LBH (Brest) E-mail : audric.vigier@ifremer.fr Tel : +33 (0)2 40 37 41 64 (8164)
Le 13/09/2017 à 16:53, Audric Vigier a écrit :
Le 12/09/2017 15:50, Eric Chatellier a écrit :
Possible, mais ce n'est pas systématique, j'ai retrouvé des machines plantées avec moins de simus que de coeurs en cours. Je ne comprend pas pourquoi mais Isis crée plein de thread et ne les libère
Le 11/09/2017 à 18:05, Audric Vigier a écrit : pas :(
On arrive à la limite de la machine en nombre de thread (31196).
En attenant de trouver la cause, il est possible d'augmenter la limite avec "ulimit -u 131072" par exemple. J'ai relancé des plans qui font entre 4000 et 6000 simus sur 4 machines en local, en augmentant la limite comme suggéré. Je me suis basé sur le nombre de simus précédemment effectué et celui que je voulais avec ces nouveaux plans, j'ai multiplié les limites par entre 1.5 et 6 fois en fonction des machines. J'ai ugmenté les limites et lancé ISIS en super utilisateur pour être de bénéficier de cette augmentation. Les machines de Sigrid et Youen ont déjà affiché 2 pop-ups "Unable to create new native thread", après qq centaines de simus. Les plans continuent de tourner, mais j'ai peur de vivre la même mésaventure. A suivre...
Tu peux retester avec cette version : https://forge.codelutin.com/attachments/download/4753/isis-fish-4.4.1.0-r442... ? (mail de devel). -- Éric Chatellier - www.codelutin.com - 02.40.50.29.28
Le 13/09/2017 à 16:53, Audric Vigier a écrit : Le 12/09/2017 15:50, Eric Chatellier a écrit : Le 11/09/2017 à 18:05, Audric Vigier a écrit : Possible, mais ce n'est pas systématique, j'ai retrouvé des machines plantées avec moins de simus que de coeurs en cours. Je ne comprend pas pourquoi mais Isis crée plein de thread et ne les libère pas :(
On arrive à la limite de la machine en nombre de thread (31196).
En attenant de trouver la cause, il est possible d'augmenter la limite avec "ulimit -u 131072" par exemple. J'ai relancé des plans qui font entre 4000 et 6000 simus sur 4 machines en local, en augmentant la limite comme suggéré. Je me suis basé sur le nombre de simus précédemment effectué et celui que je voulais avec ces nouveaux
Le 2017-09-14 09:31, Eric Chatellier a écrit : plans, j'ai multiplié les limites par entre 1.5 et 6 fois en fonction des machines. J'ai ugmenté les limites et lancé ISIS en super utilisateur pour être de bénéficier de cette augmentation. Les machines de Sigrid et Youen ont déjà affiché 2 pop-ups "Unable to create new native thread", après qq centaines de simus. Les plans continuent de tourner, mais j'ai peur de vivre la même mésaventure. A suivre... Tu peux retester avec cette version : https://forge.codelutin.com/attachments/download/4753/isis-fish-4.4.1.0-r442... ? (mail de devel). Je confirme que les ISIS se sont arrêtés chez Youen, Sigrid et EMH, seul celui sur Steph continue de tourner sans encombre. Je veux tester la nouvelle version. -- Audric Vigier Doctorant à Ifremer, unités EMH (Nantes) et STH/LBH (Brest) E-mail : audric.vigier@ifremer.fr Tel : +33 (0)2 40 37 41 64 (8164)
Tu peux retester avec cette version : https://forge.codelutin.com/attachments/download/4753/isis-fish-4.4.1.0-r442... ? (mail de devel).
Je confirme que les ISIS se sont arrêtés chez Youen, Sigrid et EMH, seul celui sur Steph continue de tourner sans encombre. Je veux tester la nouvelle version.
Est-ce qu'il y a du mieux avec cette version ? -- Éric Chatellier
Le 2017-09-14 20:56, Eric Chatellier a écrit :
Tu peux retester avec cette version : https://forge.codelutin.com/attachments/download/4753/isis-fish-4.4.1.0-r442... ? (mail de devel).
Je confirme que les ISIS se sont arrêtÃ(c)s chez Youen, Sigrid et EMH, seul celui sur Steph continue de tourner sans encombre. Je veux tester la nouvelle version.
Est-ce qu'il y a du mieux avec cette version ?
Oui, problème résolu avec cette version. Merci!
-- Audric Vigier Doctorant à Ifremer, unités EMH (Nantes) et STH/LBH (Brest) E-mail : audric.vigier@ifremer.fr Tel : +33 (0)2 40 37 41 64 (8164)
Le 11/09/2017 à 09:33, Eric Chatellier a écrit :
Le 08/09/2017 à 16:20, Audric Vigier a écrit :
Bon du coup je vais relancer mes plans, même s'il est fort probable qu'ils s'arrêtent ce week-end....
Je suis en train de faire tourner un grand nombre de simulation pour voir si je reproduit le problème. Ca a pris la journée pour faire 3000 simulations, et ca n'a pas planté :( (les simulations étaient quand même plus simples).
Et je ne vois aucune surcharge mémoire, ou trop de threads démarrés... -- Éric Chatellier - www.codelutin.com - 02.40.50.29.28
participants (2)
-
Audric Vigier -
Eric Chatellier