Re: Disabled Nagging on vmgump
On 2010-08-18, Stefan Bodewig wrote: I'll play around with Gump's support for running a shell script after a Gump run in order to kill any surefirebooter java processes still alive. The simplistic script I've added seems to work reliably, I've re-enabled nagging on vmgump. Stefan - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Disabled Nagging on vmgump
Hi, just before the current Gump run started I performed an upgrade on vmgump which updated openjdk (I was hoping it could fix the batik issues). Instead of being helpful it seems to now terminate all forked VMs after a certain amount of time - unless anything else is responsible for this, that is. Until this has been resolved I have disabled nagging completely. Stefan - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: Disabled Nagging on vmgump
On 2010-08-17, Stefan Bodewig wrote: Instead of being helpful it seems to now terminate all forked VMs after a certain amount of time - unless anything else is responsible for this, that is. Linux's oom-killer is repeatedly terminating java and python processes. Looking through the logs I see it has happened in the past as well but happens way more often this time around. Any ideas? Stefan - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: Disabled Nagging on vmgump
On 2010-08-17, Stefan Bodewig wrote: On 2010-08-17, Stefan Bodewig wrote: Instead of being helpful it seems to now terminate all forked VMs after a certain amount of time - unless anything else is responsible for this, that is. Linux's oom-killer is repeatedly terminating java and python processes. Looking through the logs I see it has happened in the past as well but happens way more often this time around. After the Gump run was finished there still where about ten or fifteen java processes active, all of them running surefire-booter-something.jar. They may be leftovers from when Gump terminates a build process, I'll keep an eye on it. After I killed the processes the machine immediately reclaimed several hundred MB of swap space. The current run has been able to build ooxml-schemas, one of our bigger memory consumers and memory is no real issue (still about 1.8GB of swap available). Given the machine has 1GB of physical memory and 2GB swap space we should be able to finish Gump withou any memory upgrade. I'll revisit the surefire-booter case and add a cron job to kill such processes if necessary. Stefan - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
