Out of memory error; java heap space; GC overhead limit exceeded
Bonjour, Je fais tourner mes simulations sur une longue durée; 40 ans, au lieu de 10 habituellement. Je les ai fait tourner dans un plan de simulation test (21 simulations, pour 19 en //; je sais c'est pas malin, mais l'idée étant de faire tourner ça la nuit ça allait). Elles ne sont pas allées jusqu'aux 40 ans, mais se sont arrêtées avant, entre 36 et 39 ans ; voir PJ. En regardant dans le debug des simulations, je retrouve 20 fois Java heap space, et une fois GC overhead limit exceeded (voir bas de message pour les 3 différentes erreurs que j'ai trouvées dans le debug) Je travaille avec des simulations utilisant 4 règles, dont 2 produisent des .csv (5.5MB pour le plus lourd). Elles ont besoin de paramètres définis dans le contexte (context.setComputeValue[...]), il y en a des milliers. Je demande à supprimer les résultats après les exports (bien qu'en réalité, le répertoire results/matrix de chaque simulation contient plein de .gz). Je sauvegarde 4 exports : Abondances, AbondancesBeginMonth, CapturesNombre et RejetsNombre. Les 2 derniers sont très lourds et avoisinent les 1GB chacun; contre environ 25 MB pour chaque export d'abondance. Quelles pistes pour éviter d'en demander trop à ISIS? A+ Audric ERROR|17:35:59,883|InProcessSimulatorLauncher.java|476|localSimulateSameThread|Error during simulation java.lang.OutOfMemoryError: GC overhead limit exceeded at java.util.Arrays.copyOf(Unknown Source) ~[?:1.8.0_211] at java.lang.AbstractStringBuilder.ensureCapacityInternal(Unknown Source) ~[?:1.8.0_211] at java.lang.AbstractStringBuilder.append(Unknown Source) ~[?:1.8.0_211] at java.lang.StringBuilder.append(Unknown Source) ~[?:1.8.0_211] at java.lang.StringBuilder.append(Unknown Source) ~[?:1.8.0_211] at simulators.DefaultSimulatorResultBeforeCondition.computeMonth(DefaultSimulatorResultBeforeCondition.java:450) ~[?:?] at simulators.DefaultSimulatorResultBeforeCondition.simulate(DefaultSimulatorResultBeforeCondition.java:259) ~[?:?] at fr.ifremer.isisfish.simulator.launcher.InProcessSimulatorLauncher.localSimulateSameThread(InProcessSimulatorLauncher.java:430) [isis-fish-4.4.2.2.jar:4.4.2.2] at fr.ifremer.isisfish.simulator.launcher.InProcessSimulatorLauncher$SimThread.run(InProcessSimulatorLauncher.java:260) [isis-fish-4.4.2.2.jar:4.4.2.2] ERROR|17:35:59,914|DriverManagerConnectionProviderImpl.java|332|close|Connection leak detected: there are 3 unclosed connections upon shutting down pool jdbc:h2:file:D:\isis-fish-4\isis-database\simulations\sim_MSYDerivationTest_2019-10-08-13-47_6\data\data;FILE_LOCK=file;LOG=1;AUTO_SERVER=TRUE;DEFAULT_LOCK_TIMEOUT=1000;DB_CLOSE_DELAY=0;LOCK_MODE=3;TRACE_LEVEL_FILE=0;TRACE_LEVEL_SYSTEM_OUT=0 ERROR|17:40:33,132|InProcessSimulatorLauncher.java|476|localSimulateSameThread|Error during simulation java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOfRange(Unknown Source) ~[?:1.8.0_211] at java.lang.StringBuffer.toString(Unknown Source) ~[?:1.8.0_211] at org.nuiton.math.matrix.BasicMatrix.toString(BasicMatrix.java:380) ~[nuiton-matrix-2.5.2.jar:2.5.2] at org.nuiton.math.matrix.MatrixNDImpl.toString(MatrixNDImpl.java:206) ~[nuiton-matrix-2.5.2.jar:2.5.2] at java.lang.String.valueOf(Unknown Source) ~[?:1.8.0_211] at java.lang.StringBuilder.append(Unknown Source) ~[?:1.8.0_211] at simulators.DefaultSimulatorResultBeforeCondition.computeMonth(DefaultSimulatorResultBeforeCondition.java:446) ~[?:?] at simulators.DefaultSimulatorResultBeforeCondition.simulate(DefaultSimulatorResultBeforeCondition.java:259) ~[?:?] at fr.ifremer.isisfish.simulator.launcher.InProcessSimulatorLauncher.localSimulateSameThread(InProcessSimulatorLauncher.java:430) [isis-fish-4.4.2.2.jar:4.4.2.2] at fr.ifremer.isisfish.simulator.launcher.InProcessSimulatorLauncher$SimThread.run(InProcessSimulatorLauncher.java:260) [isis-fish-4.4.2.2.jar:4.4.2.2] ERROR|17:40:33,148|DriverManagerConnectionProviderImpl.java|332|close|Connection leak detected: there are 3 unclosed connections upon shutting down pool jdbc:h2:file:D:\isis-fish-4\isis-database\simulations\sim_MSYDerivationTest_2019-10-08-13-47_13\data\data;FILE_LOCK=file;LOG=1;AUTO_SERVER=TRUE;DEFAULT_LOCK_TIMEOUT=1000;DB_CLOSE_DELAY=0;LOCK_MODE=3;TRACE_LEVEL_FILE=0;TRACE_LEVEL_SYSTEM_OUT=0 ERROR|17:35:59,883|InProcessSimulatorLauncher.java|476|localSimulateSameThread|Error during simulation java.lang.OutOfMemoryError: GC overhead limit exceeded at java.util.Arrays.copyOf(Unknown Source) ~[?:1.8.0_211] at java.lang.AbstractStringBuilder.ensureCapacityInternal(Unknown Source) ~[?:1.8.0_211] at java.lang.AbstractStringBuilder.append(Unknown Source) ~[?:1.8.0_211] at java.lang.StringBuilder.append(Unknown Source) ~[?:1.8.0_211] at java.lang.StringBuilder.append(Unknown Source) ~[?:1.8.0_211] at simulators.DefaultSimulatorResultBeforeCondition.computeMonth(DefaultSimulatorResultBeforeCondition.java:450) ~[?:?] at simulators.DefaultSimulatorResultBeforeCondition.simulate(DefaultSimulatorResultBeforeCondition.java:259) ~[?:?] at fr.ifremer.isisfish.simulator.launcher.InProcessSimulatorLauncher.localSimulateSameThread(InProcessSimulatorLauncher.java:430) [isis-fish-4.4.2.2.jar:4.4.2.2] at fr.ifremer.isisfish.simulator.launcher.InProcessSimulatorLauncher$SimThread.run(InProcessSimulatorLauncher.java:260) [isis-fish-4.4.2.2.jar:4.4.2.2] ERROR|17:35:59,914|DriverManagerConnectionProviderImpl.java|332|close|Connection leak detected: there are 3 unclosed connections upon shutting down pool jdbc:h2:file:D:\isis-fish-4\isis-database\simulations\sim_MSYDerivationTest_2019-10-08-13-47_6\data\data;FILE_LOCK=file;LOG=1;AUTO_SERVER=TRUE;DEFAULT_LOCK_TIMEOUT=1000;DB_CLOSE_DELAY=0;LOCK_MODE=3;TRACE_LEVEL_FILE=0;TRACE_LEVEL_SYSTEM_OUT=0
Re-bonjour, J'ai essayé en augmentant la taille du tas en modifiant le .bat (java -Xmx100000000000 -jar isis-fish-4.4.2.2.jar [...]), j'ai toujours le même problème. Je suis coincé et je dois impérativement faire tourner des simulations plus longues (100 ans). Que faire? Audric ________________________________ From: Isis-fish-users <isis-fish-users-bounces@list.isis-fish.org> on behalf of Audric Vigier <A.Vigier@qub.ac.uk> Sent: 09 October 2019 10:43 To: isis-fish-users@list.isis-fish.org <isis-fish-users@list.isis-fish.org> Subject: [Isis-fish-users] Out of memory error; java heap space; GC overhead limit exceeded Bonjour, Je fais tourner mes simulations sur une longue durée; 40 ans, au lieu de 10 habituellement. Je les ai fait tourner dans un plan de simulation test (21 simulations, pour 19 en //; je sais c'est pas malin, mais l'idée étant de faire tourner ça la nuit ça allait). Elles ne sont pas allées jusqu'aux 40 ans, mais se sont arrêtées avant, entre 36 et 39 ans ; voir PJ. En regardant dans le debug des simulations, je retrouve 20 fois Java heap space, et une fois GC overhead limit exceeded (voir bas de message pour les 3 différentes erreurs que j'ai trouvées dans le debug) Je travaille avec des simulations utilisant 4 règles, dont 2 produisent des .csv (5.5MB pour le plus lourd). Elles ont besoin de paramètres définis dans le contexte (context.setComputeValue[...]), il y en a des milliers. Je demande à supprimer les résultats après les exports (bien qu'en réalité, le répertoire results/matrix de chaque simulation contient plein de .gz). Je sauvegarde 4 exports : Abondances, AbondancesBeginMonth, CapturesNombre et RejetsNombre. Les 2 derniers sont très lourds et avoisinent les 1GB chacun; contre environ 25 MB pour chaque export d'abondance. Quelles pistes pour éviter d'en demander trop à ISIS? A+ Audric ERROR|17:35:59,883|InProcessSimulatorLauncher.java|476|localSimulateSameThread|Error during simulation java.lang.OutOfMemoryError: GC overhead limit exceeded at java.util.Arrays.copyOf(Unknown Source) ~[?:1.8.0_211] at java.lang.AbstractStringBuilder.ensureCapacityInternal(Unknown Source) ~[?:1.8.0_211] at java.lang.AbstractStringBuilder.append(Unknown Source) ~[?:1.8.0_211] at java.lang.StringBuilder.append(Unknown Source) ~[?:1.8.0_211] at java.lang.StringBuilder.append(Unknown Source) ~[?:1.8.0_211] at simulators.DefaultSimulatorResultBeforeCondition.computeMonth(DefaultSimulatorResultBeforeCondition.java:450) ~[?:?] at simulators.DefaultSimulatorResultBeforeCondition.simulate(DefaultSimulatorResultBeforeCondition.java:259) ~[?:?] at fr.ifremer.isisfish.simulator.launcher.InProcessSimulatorLauncher.localSimulateSameThread(InProcessSimulatorLauncher.java:430) [isis-fish-4.4.2.2.jar:4.4.2.2] at fr.ifremer.isisfish.simulator.launcher.InProcessSimulatorLauncher$SimThread.run(InProcessSimulatorLauncher.java:260) [isis-fish-4.4.2.2.jar:4.4.2.2] ERROR|17:35:59,914|DriverManagerConnectionProviderImpl.java|332|close|Connection leak detected: there are 3 unclosed connections upon shutting down pool jdbc:h2:file:D:\isis-fish-4\isis-database\simulations\sim_MSYDerivationTest_2019-10-08-13-47_6\data\data;FILE_LOCK=file;LOG=1;AUTO_SERVER=TRUE;DEFAULT_LOCK_TIMEOUT=1000;DB_CLOSE_DELAY=0;LOCK_MODE=3;TRACE_LEVEL_FILE=0;TRACE_LEVEL_SYSTEM_OUT=0 ERROR|17:40:33,132|InProcessSimulatorLauncher.java|476|localSimulateSameThread|Error during simulation java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOfRange(Unknown Source) ~[?:1.8.0_211] at java.lang.StringBuffer.toString(Unknown Source) ~[?:1.8.0_211] at org.nuiton.math.matrix.BasicMatrix.toString(BasicMatrix.java:380) ~[nuiton-matrix-2.5.2.jar:2.5.2] at org.nuiton.math.matrix.MatrixNDImpl.toString(MatrixNDImpl.java:206) ~[nuiton-matrix-2.5.2.jar:2.5.2] at java.lang.String.valueOf(Unknown Source) ~[?:1.8.0_211] at java.lang.StringBuilder.append(Unknown Source) ~[?:1.8.0_211] at simulators.DefaultSimulatorResultBeforeCondition.computeMonth(DefaultSimulatorResultBeforeCondition.java:446) ~[?:?] at simulators.DefaultSimulatorResultBeforeCondition.simulate(DefaultSimulatorResultBeforeCondition.java:259) ~[?:?] at fr.ifremer.isisfish.simulator.launcher.InProcessSimulatorLauncher.localSimulateSameThread(InProcessSimulatorLauncher.java:430) [isis-fish-4.4.2.2.jar:4.4.2.2] at fr.ifremer.isisfish.simulator.launcher.InProcessSimulatorLauncher$SimThread.run(InProcessSimulatorLauncher.java:260) [isis-fish-4.4.2.2.jar:4.4.2.2] ERROR|17:40:33,148|DriverManagerConnectionProviderImpl.java|332|close|Connection leak detected: there are 3 unclosed connections upon shutting down pool jdbc:h2:file:D:\isis-fish-4\isis-database\simulations\sim_MSYDerivationTest_2019-10-08-13-47_13\data\data;FILE_LOCK=file;LOG=1;AUTO_SERVER=TRUE;DEFAULT_LOCK_TIMEOUT=1000;DB_CLOSE_DELAY=0;LOCK_MODE=3;TRACE_LEVEL_FILE=0;TRACE_LEVEL_SYSTEM_OUT=0 ERROR|17:35:59,883|InProcessSimulatorLauncher.java|476|localSimulateSameThread|Error during simulation java.lang.OutOfMemoryError: GC overhead limit exceeded at java.util.Arrays.copyOf(Unknown Source) ~[?:1.8.0_211] at java.lang.AbstractStringBuilder.ensureCapacityInternal(Unknown Source) ~[?:1.8.0_211] at java.lang.AbstractStringBuilder.append(Unknown Source) ~[?:1.8.0_211] at java.lang.StringBuilder.append(Unknown Source) ~[?:1.8.0_211] at java.lang.StringBuilder.append(Unknown Source) ~[?:1.8.0_211] at simulators.DefaultSimulatorResultBeforeCondition.computeMonth(DefaultSimulatorResultBeforeCondition.java:450) ~[?:?] at simulators.DefaultSimulatorResultBeforeCondition.simulate(DefaultSimulatorResultBeforeCondition.java:259) ~[?:?] at fr.ifremer.isisfish.simulator.launcher.InProcessSimulatorLauncher.localSimulateSameThread(InProcessSimulatorLauncher.java:430) [isis-fish-4.4.2.2.jar:4.4.2.2] at fr.ifremer.isisfish.simulator.launcher.InProcessSimulatorLauncher$SimThread.run(InProcessSimulatorLauncher.java:260) [isis-fish-4.4.2.2.jar:4.4.2.2] ERROR|17:35:59,914|DriverManagerConnectionProviderImpl.java|332|close|Connection leak detected: there are 3 unclosed connections upon shutting down pool jdbc:h2:file:D:\isis-fish-4\isis-database\simulations\sim_MSYDerivationTest_2019-10-08-13-47_6\data\data;FILE_LOCK=file;LOG=1;AUTO_SERVER=TRUE;DEFAULT_LOCK_TIMEOUT=1000;DB_CLOSE_DELAY=0;LOCK_MODE=3;TRACE_LEVEL_FILE=0;TRACE_LEVEL_SYSTEM_OUT=0
Le 11/10/2019 à 10:23, Audric Vigier a écrit :
Re-bonjour,
J'ai essayé en augmentant la taille du tas en modifiant le .bat (java -Xmx100000000000 -jar isis-fish-4.4.2.2.jar [...]), j'ai toujours le même problème. Je suis coincé et je dois impérativement faire tourner des simulations plus longues (100 ans). Que faire?
C'est plutôt les sous-simulations en sous processus qui plantent non ? Auquel cas, c'est le paramêtre "simulation.sub.max.memory" qu'il faut modifier dans la configuration.
(21 simulations, pour 19 en //; Tu as au moins 19Go de ram dispo sur ton poste ? Sinon, il va certainement avoir un problème oui.
Et si tu passe le parametre "simulation.sub.max.memory" à 2048Mo, avec 19 simu en parallèle, il faudrait que tu ai 38 Go de ram pour les sous simulations, sinon il faudra réduire le nombre en parallèle. -- Éric Chatellier - www.codelutin.com - 02.40.50.29.28
Salut, J'ai 128GB au total. Oui c'est les sous-simulations qui plantent, une à une, pas le plan en lui-même. Je viens de fixer simulation.sub.max.memory à 4096MB, je vais voir ce que ça donne. ________________________________ From: Isis-fish-users <isis-fish-users-bounces@list.isis-fish.org> on behalf of Eric Chatellier <chatellier@codelutin.com> Sent: 11 October 2019 10:02 To: isis-fish-users@list.isis-fish.org <isis-fish-users@list.isis-fish.org> Subject: Re: [Isis-fish-users] Out of memory error; java heap space; GC overhead limit exceeded Le 11/10/2019 à 10:23, Audric Vigier a écrit :
Re-bonjour,
J'ai essayé en augmentant la taille du tas en modifiant le .bat (java -Xmx100000000000 -jar isis-fish-4.4.2.2.jar [...]), j'ai toujours le même problème. Je suis coincé et je dois impérativement faire tourner des simulations plus longues (100 ans). Que faire?
C'est plutôt les sous-simulations en sous processus qui plantent non ? Auquel cas, c'est le paramêtre "simulation.sub.max.memory" qu'il faut modifier dans la configuration.
(21 simulations, pour 19 en //; Tu as au moins 19Go de ram dispo sur ton poste ? Sinon, il va certainement avoir un problème oui.
Et si tu passe le parametre "simulation.sub.max.memory" à 2048Mo, avec 19 simu en parallèle, il faudrait que tu ai 38 Go de ram pour les sous simulations, sinon il faudra réduire le nombre en parallèle. -- Éric Chatellier - www.codelutin.com<http://www.codelutin.com> - 02.40.50.29.28 _______________________________________________ Isis-fish-users mailing list Isis-fish-users@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-users
Mes simus ont toutes dépassé les 40 ans, donc a priori problème résolu. Merci pour la suggestion! ________________________________ From: Isis-fish-users <isis-fish-users-bounces@list.isis-fish.org> on behalf of Audric Vigier <A.Vigier@qub.ac.uk> Sent: 11 October 2019 10:11 To: isis-fish-users@list.isis-fish.org <isis-fish-users@list.isis-fish.org> Subject: Re: [Isis-fish-users] Out of memory error; java heap space; GC overhead limit exceeded Salut, J'ai 128GB au total. Oui c'est les sous-simulations qui plantent, une à une, pas le plan en lui-même. Je viens de fixer simulation.sub.max.memory à 4096MB, je vais voir ce que ça donne. ________________________________ From: Isis-fish-users <isis-fish-users-bounces@list.isis-fish.org> on behalf of Eric Chatellier <chatellier@codelutin.com> Sent: 11 October 2019 10:02 To: isis-fish-users@list.isis-fish.org <isis-fish-users@list.isis-fish.org> Subject: Re: [Isis-fish-users] Out of memory error; java heap space; GC overhead limit exceeded Le 11/10/2019 à 10:23, Audric Vigier a écrit :
Re-bonjour,
J'ai essayé en augmentant la taille du tas en modifiant le .bat (java -Xmx100000000000 -jar isis-fish-4.4.2.2.jar [...]), j'ai toujours le même problème. Je suis coincé et je dois impérativement faire tourner des simulations plus longues (100 ans). Que faire?
C'est plutôt les sous-simulations en sous processus qui plantent non ? Auquel cas, c'est le paramêtre "simulation.sub.max.memory" qu'il faut modifier dans la configuration.
(21 simulations, pour 19 en //; Tu as au moins 19Go de ram dispo sur ton poste ? Sinon, il va certainement avoir un problème oui.
Et si tu passe le parametre "simulation.sub.max.memory" à 2048Mo, avec 19 simu en parallèle, il faudrait que tu ai 38 Go de ram pour les sous simulations, sinon il faudra réduire le nombre en parallèle. -- Éric Chatellier - www.codelutin.com<http://www.codelutin.com> - 02.40.50.29.28 _______________________________________________ Isis-fish-users mailing list Isis-fish-users@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-users
Bonjour, Je suis en train de tenter de lancer une analyse de sensibilité, avec 19 runs en parallèle. Le "plan" de l'AS est bien initialisé, les 19 premières simus se lancent, 5 atteignent février, et tout se bloque, avec des temps annoncés de simulation délirants (26h au lieu d'1h en version non AS ; et 1h-1h30 lors des AS que je faisais il y a quelques mois). Quand je regarde l'état des processeurs dans le gestionnaire des tâches, il n'y a aucune activité. Je dois arrêter toutes les simulations, fermer ISIS, et tuer à la main tous les processus Java dans le gestionnaire des tâches. Même en descendant à 5 simus en parallèle, le problème s'est manifesté (mais en avril au lieu de février). Je suis descendu à 2 simus pour que ça ne se produise plus. Mais à ce rythme là je ne suis pas prêt d'en voir la fin... Juste pour voir, j'ai relancé une AS légèrement différente, que j'utilisais il y a quelques mois. Elle s'est lancée sans encombre avec 19 simus en parallèle, avec des temps de simus habituels (1h-1h30). La config que j'ai utilisée pour les 2 AS est en PJ. Dans la première AS (celle qui coince), je dois donc trop en demander quelque part. Pourtant les bases et simulations que j'ai utilisées pour créer les AS ne sont pas si différentes. Qu'est-ce qui peut provoquer ce genre de comportement? Audric ________________________________ From: Isis-fish-users <isis-fish-users-bounces@list.isis-fish.org> on behalf of Audric Vigier <A.Vigier@qub.ac.uk> Sent: 11 October 2019 17:12 To: isis-fish-users@list.isis-fish.org <isis-fish-users@list.isis-fish.org> Subject: Re: [Isis-fish-users] Out of memory error; java heap space; GC overhead limit exceeded Mes simus ont toutes dépassé les 40 ans, donc a priori problème résolu. Merci pour la suggestion! ________________________________ From: Isis-fish-users <isis-fish-users-bounces@list.isis-fish.org> on behalf of Audric Vigier <A.Vigier@qub.ac.uk> Sent: 11 October 2019 10:11 To: isis-fish-users@list.isis-fish.org <isis-fish-users@list.isis-fish.org> Subject: Re: [Isis-fish-users] Out of memory error; java heap space; GC overhead limit exceeded Salut, J'ai 128GB au total. Oui c'est les sous-simulations qui plantent, une à une, pas le plan en lui-même. Je viens de fixer simulation.sub.max.memory à 4096MB, je vais voir ce que ça donne. ________________________________ From: Isis-fish-users <isis-fish-users-bounces@list.isis-fish.org> on behalf of Eric Chatellier <chatellier@codelutin.com> Sent: 11 October 2019 10:02 To: isis-fish-users@list.isis-fish.org <isis-fish-users@list.isis-fish.org> Subject: Re: [Isis-fish-users] Out of memory error; java heap space; GC overhead limit exceeded Le 11/10/2019 à 10:23, Audric Vigier a écrit :
Re-bonjour,
J'ai essayé en augmentant la taille du tas en modifiant le .bat (java -Xmx100000000000 -jar isis-fish-4.4.2.2.jar [...]), j'ai toujours le même problème. Je suis coincé et je dois impérativement faire tourner des simulations plus longues (100 ans). Que faire?
C'est plutôt les sous-simulations en sous processus qui plantent non ? Auquel cas, c'est le paramêtre "simulation.sub.max.memory" qu'il faut modifier dans la configuration.
(21 simulations, pour 19 en //; Tu as au moins 19Go de ram dispo sur ton poste ? Sinon, il va certainement avoir un problème oui.
Et si tu passe le parametre "simulation.sub.max.memory" à 2048Mo, avec 19 simu en parallèle, il faudrait que tu ai 38 Go de ram pour les sous simulations, sinon il faudra réduire le nombre en parallèle. -- Éric Chatellier - www.codelutin.com<http://www.codelutin.com> - 02.40.50.29.28 _______________________________________________ Isis-fish-users mailing list Isis-fish-users@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-users
Bonjour, On Sat, 5 Sep 2020 18:32:48 +0000 Audric Vigier <A.Vigier@qub.ac.uk> wrote:
Je suis en train de tenter de lancer une analyse de sensibilité, avec 19 runs en parallèle. Le "plan" de l'AS est bien initialisé, les 19 premières simus se lancent, 5 atteignent février, et tout se bloque, avec des temps annoncés de simulation délirants (26h au lieu d'1h en version non AS ; et 1h-1h30 lors des AS que je faisais il y a quelques mois). Quand je regarde l'état des processeurs dans le gestionnaire des tâches, il n'y a aucune activité. Je dois arrêter toutes les simulations, fermer ISIS, et tuer à la main tous les processus Java dans le gestionnaire des tâches. Même en descendant à 5 simus en parallèle, le problème s'est manifesté (mais en avril au lieu de février). Je suis descendu à 2 simus pour que ça ne se produise plus. Mais à ce rythme là je ne suis pas prêt d'en voir la fin...
Juste pour voir, j'ai relancé une AS légèrement différente, que j'utilisais il y a quelques mois. Elle s'est lancée sans encombre avec 19 simus en parallèle, avec des temps de simus habituels (1h-1h30). La config que j'ai utilisée pour les 2 AS est en PJ.
Dans la première AS (celle qui coince), je dois donc trop en demander quelque part. Pourtant les bases et simulations que j'ai utilisées pour créer les AS ne sont pas si différentes. Qu'est-ce qui peut provoquer ce genre de comportement?
Tu as des choses dans les logs ? Le PC rame par ailleurs ? Jean
Bonjour, Non, je n'ai rien trouvé dans les logs. Je n'ai pas essayé de faire autre chose sur ce PC pendant que l'AS tournait, le but étant de laisser le plus de ressources possibles pour l'AS. Cependant: -Pour l'ancienne AS, celle qui tourne normalement, le PC ne rame pas -Pour la nouvelle, qui ne tourne pas, le PC rame au moment de lancer les premières simus (CPU usage à 100% pour tous les coeurs, je suppose qu'il configure toutes les simus de l'AS en même temps?), puis pendant quelques minutes, CPU usage plus faible avec les simulations qui se déroulent (ça ne rame plus), puis plus d'activité du tout. Il y a 128GB de RAM et chaque sous-processus peut en prendre jusqu'à 4, donc la RAM n'était jamais utilisée à 100%. Audric ________________________________ From: Isis-fish-users <isis-fish-users-bounces@list.isis-fish.org> on behalf of Jean Couteau <couteau@codelutin.com> Sent: 07 September 2020 10:14 To: isis-fish-users@list.isis-fish.org <isis-fish-users@list.isis-fish.org> Subject: Re: [Isis-fish-users] Analyse de sensibilité et simus très lentes This message is from an external sender. Please take care when responding, clicking links or opening attachments. Bonjour, On Sat, 5 Sep 2020 18:32:48 +0000 Audric Vigier <A.Vigier@qub.ac.uk> wrote:
Je suis en train de tenter de lancer une analyse de sensibilité, avec 19 runs en parallèle. Le "plan" de l'AS est bien initialisé, les 19 premières simus se lancent, 5 atteignent février, et tout se bloque, avec des temps annoncés de simulation délirants (26h au lieu d'1h en version non AS ; et 1h-1h30 lors des AS que je faisais il y a quelques mois). Quand je regarde l'état des processeurs dans le gestionnaire des tâches, il n'y a aucune activité. Je dois arrêter toutes les simulations, fermer ISIS, et tuer à la main tous les processus Java dans le gestionnaire des tâches. Même en descendant à 5 simus en parallèle, le problème s'est manifesté (mais en avril au lieu de février). Je suis descendu à 2 simus pour que ça ne se produise plus. Mais à ce rythme là je ne suis pas prêt d'en voir la fin...
Juste pour voir, j'ai relancé une AS légèrement différente, que j'utilisais il y a quelques mois. Elle s'est lancée sans encombre avec 19 simus en parallèle, avec des temps de simus habituels (1h-1h30). La config que j'ai utilisée pour les 2 AS est en PJ.
Dans la première AS (celle qui coince), je dois donc trop en demander quelque part. Pourtant les bases et simulations que j'ai utilisées pour créer les AS ne sont pas si différentes. Qu'est-ce qui peut provoquer ce genre de comportement?
Tu as des choses dans les logs ? Le PC rame par ailleurs ? Jean _______________________________________________ Isis-fish-users mailing list Isis-fish-users@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-users
Re, En re-parcourant le debug, je suis tombé sur ce genre d'erreur, mais pour les 2 AS. Peut-être une piste? 2020-09-07 10:42:20,822 INFO [Thread-56] (SubProcessSimulationLauncher.java:302) run - dans un sous processus>2020-09-07 10:42:20,821 ERROR [main] (DriverManagerConnectionProviderImpl.java:332) close - Connection leak detected: there are 1 unclosed connections upon shutting down pool jdbc:h2:file:D:\isis-fish-4\isis-database\simulations\as_sept2020_2020-09-07-10-42_17\data\data;FILE_LOCK=file;LOG=1;AUTO_SERVER=TRUE;DEFAULT_LOCK_TIMEOUT=1000;DB_CLOSE_DELAY=0;LOCK_MODE=3;TRACE_LEVEL_FILE=0;TRACE_LEVEL_SYSTEM_OUT=0 2020-09-07 10:42:20,842 INFO [Thread-56] (SubProcessSimulationLauncher.java:302) run - dans un sous processus>2020-09-07 10:42:20,841 ERROR [main] (DriverManagerConnectionProviderImpl.java:332) close - Connection leak detected: there are 1 unclosed connections upon shutting down pool jdbc:h2:file:D:\isis-fish-4\isis-database\simulations\as_sept2020_2020-09-07-10-42_17\data\data;FILE_LOCK=file;LOG=1;AUTO_SERVER=TRUE;DEFAULT_LOCK_TIMEOUT=1000;DB_CLOSE_DELAY=0;LOCK_MODE=3;TRACE_LEVEL_FILE=0;TRACE_LEVEL_SYSTEM_OUT=0 2020-09-07 10:42:20,859 INFO [Thread-56] (SubProcessSimulationLauncher.java:302) run - dans un sous processus>2020-09-07 10:42:20,857 ERROR [main] (DriverManagerConnectionProviderImpl.java:332) close - Connection leak detected: there are 1 unclosed connections upon shutting down pool jdbc:h2:file:D:\isis-fish-4\isis-database\simulations\as_sept2020_2020-09-07-10-42_17\data\data;FILE_LOCK=file;LOG=1;AUTO_SERVER=TRUE;DEFAULT_LOCK_TIMEOUT=1000;DB_CLOSE_DELAY=0;LOCK_MODE=3;TRACE_LEVEL_FILE=0;TRACE_LEVEL_SYSTEM_OUT=0 ________________________________ From: Isis-fish-users <isis-fish-users-bounces@list.isis-fish.org> on behalf of Audric Vigier <A.Vigier@qub.ac.uk> Sent: 07 September 2020 10:31 To: isis-fish-users@list.isis-fish.org <isis-fish-users@list.isis-fish.org> Subject: Re: [Isis-fish-users] Analyse de sensibilité et simus très lentes Bonjour, Non, je n'ai rien trouvé dans les logs. Je n'ai pas essayé de faire autre chose sur ce PC pendant que l'AS tournait, le but étant de laisser le plus de ressources possibles pour l'AS. Cependant: -Pour l'ancienne AS, celle qui tourne normalement, le PC ne rame pas -Pour la nouvelle, qui ne tourne pas, le PC rame au moment de lancer les premières simus (CPU usage à 100% pour tous les coeurs, je suppose qu'il configure toutes les simus de l'AS en même temps?), puis pendant quelques minutes, CPU usage plus faible avec les simulations qui se déroulent (ça ne rame plus), puis plus d'activité du tout. Il y a 128GB de RAM et chaque sous-processus peut en prendre jusqu'à 4, donc la RAM n'était jamais utilisée à 100%. Audric ________________________________ From: Isis-fish-users <isis-fish-users-bounces@list.isis-fish.org> on behalf of Jean Couteau <couteau@codelutin.com> Sent: 07 September 2020 10:14 To: isis-fish-users@list.isis-fish.org <isis-fish-users@list.isis-fish.org> Subject: Re: [Isis-fish-users] Analyse de sensibilité et simus très lentes This message is from an external sender. Please take care when responding, clicking links or opening attachments. Bonjour, On Sat, 5 Sep 2020 18:32:48 +0000 Audric Vigier <A.Vigier@qub.ac.uk> wrote:
Je suis en train de tenter de lancer une analyse de sensibilité, avec 19 runs en parallèle. Le "plan" de l'AS est bien initialisé, les 19 premières simus se lancent, 5 atteignent février, et tout se bloque, avec des temps annoncés de simulation délirants (26h au lieu d'1h en version non AS ; et 1h-1h30 lors des AS que je faisais il y a quelques mois). Quand je regarde l'état des processeurs dans le gestionnaire des tâches, il n'y a aucune activité. Je dois arrêter toutes les simulations, fermer ISIS, et tuer à la main tous les processus Java dans le gestionnaire des tâches. Même en descendant à 5 simus en parallèle, le problème s'est manifesté (mais en avril au lieu de février). Je suis descendu à 2 simus pour que ça ne se produise plus. Mais à ce rythme là je ne suis pas prêt d'en voir la fin...
Juste pour voir, j'ai relancé une AS légèrement différente, que j'utilisais il y a quelques mois. Elle s'est lancée sans encombre avec 19 simus en parallèle, avec des temps de simus habituels (1h-1h30). La config que j'ai utilisée pour les 2 AS est en PJ.
Dans la première AS (celle qui coince), je dois donc trop en demander quelque part. Pourtant les bases et simulations que j'ai utilisées pour créer les AS ne sont pas si différentes. Qu'est-ce qui peut provoquer ce genre de comportement?
Tu as des choses dans les logs ? Le PC rame par ailleurs ? Jean _______________________________________________ Isis-fish-users mailing list Isis-fish-users@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-users
Le 07/09/2020 à 11:31, Audric Vigier a écrit :
Il y a 128GB de RAM et chaque sous-processus peut en prendre jusqu'à 4, donc la RAM n'était jamais utilisée à 100%.
Il y a au moins 19 coeurs (processeur) sur la machine ? Il faudrait regarder, dans le moniteur de ressouce windows pour voir ce qu'il se passe à ce moment là: - saturation mémoire - saturation processeur - saturation ecriture disque - saturation reseau (si c'est un disque réseau) Ou alors, combien de ressource prennent les 19 processus java qui doivent être en cours à ce moment là. -- Éric Chatellier - www.codelutin.com - 02.40.50.29.28
Bonjour, En reproduisant le bug hier, j'ai oublié de demander à ISIS d'arrêter les simus que je pensais à l'arrêt après 10-15 min. J'ai découvert plus tard qu'elles se sont réellement mises en route (après une bonne demie-heure), et ce matin l'AS était terminée. Le problème est donc bien moins grave (je perds 30 min sur qqchose qui prends environ 1 journée). J'ai donc une AS qui se met en route rapidement, et une autre qui a un moteur diesel. Ce n'est pas gênant à ce stade, mais il faudra que j'identifie de mon côté ce qui a pu générer ce comportement, c'est toujours mieux sans. Je vais regarder avec ta liste Eric. Merci pour votre aide, Audric ________________________________ From: Isis-fish-users <isis-fish-users-bounces@list.isis-fish.org> on behalf of Eric Chatellier <chatellier@codelutin.com> Sent: 07 September 2020 15:04 To: isis-fish-users@list.isis-fish.org <isis-fish-users@list.isis-fish.org> Subject: Re: [Isis-fish-users] Analyse de sensibilité et simus très lentes This message is from an external sender. Please take care when responding, clicking links or opening attachments. Le 07/09/2020 à 11:31, Audric Vigier a écrit :
Il y a 128GB de RAM et chaque sous-processus peut en prendre jusqu'à 4, donc la RAM n'était jamais utilisée à 100%.
Il y a au moins 19 coeurs (processeur) sur la machine ? Il faudrait regarder, dans le moniteur de ressouce windows pour voir ce qu'il se passe à ce moment là: - saturation mémoire - saturation processeur - saturation ecriture disque - saturation reseau (si c'est un disque réseau) Ou alors, combien de ressource prennent les 19 processus java qui doivent être en cours à ce moment là. -- Éric Chatellier - www.codelutin.com<http://www.codelutin.com> - 02.40.50.29.28 _______________________________________________ Isis-fish-users mailing list Isis-fish-users@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-users
participants (3)
-
Audric Vigier -
Eric Chatellier -
Jean Couteau