RE: Garbage collection, out of memory
Sounds good, but WHERE does these parameters go? I include a snippit of my orion-ejb-jar.xml file... Thanx Jaco -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Michael Doernberg Sent: 14 February 2001 01:45 To: Orion-Interest Subject: Re: Garbage collection, out of memory When you deploy your application. Orion will generate an XML file called orion-ejb-jar.xml, if one does not exist. The file is derived from your EJBs. The file can be found buried in the application-deployments directory. You can set some parameters on each EJB you deem appropriate. These parameters are not set in the auto generated file. The first is a "validity-timeout" set to milliseconds. This will passivate the the EJB if not active. The second is a parameter called "max-instances" . This is set to the max number of EJBs of a particular type you want. I am not sure if this is supported yet, but I believe it was supposed to be implemented in the 1.4.7. Hope this help. Let me know what you figure out. -Mike - Original Message - From: "Thomas Munro" <[EMAIL PROTECTED]> To: "Orion-Interest" <[EMAIL PROTECTED]> Sent: Tuesday, February 13, 2001 1:29 PM Subject: Garbage collection, out of memory > Hello > > We are experiencing a garbage collection problem. We are running Orion > 1.4.7 on a Linux 2.4 box. We have been trying the Sun 1.2.2, the Sun 1.3 > and the IBM JVM 1.3. On the Sun 1.3 JVM we have tried normal garbage > collection and also -Xincgc incremental garbage collection. We run with > 500 megabytes of heap space available to Java. > > The system uses lots of EJBs (mainly stateless session but also quite a > few entities and a handful of stateful session beans), and we have JSP > pages which run in the same JVM. > > The system runs very responsively and well, with up to 90 users > simultaneously using it, for up to an hour. Then enormous GCs start > happening which block all activity for up to 180 seconds at a time! The > length and frequency of the freezes vary with the different JVMs but all > are unusable after say an hour of up time. > > The Sun 1.3 in incremental GC mode is the best, and in fact remains stable > and usable until it starts doing a few 9 second GCs from time to time > (comparatively bearable) until we get a "HotSpot internal error" which > stops all processing. > > We are trying all sorts of different things to stop our users getting > upset, like reducing the JSP session timeout to a minimum, and are > currently trying to analyse the code with JProbe to find out how to > minimise unnecessary object creation or memory leaks (stale references to > no longer used objects etc). > > As several list members have already said, it also seems that some beans > are never passivated. > > What can we do to make Orion stop using more and more memory, and not to > cause such outrageous garbage collection cycles? > > Any comments or suggestions would be very much appreciated. > > -- > Thomas Munro <[EMAIL PROTECTED]> > http://www.fullsix.com/ > Fullsix Technology (Paris) > >
Re: RE: Garbage collection, out of memory
The problem is not that simple. There's a bug. We then ran a test program that creates a simple entity bean in an infinite loop and then releases the reference of this entity bean. We ran a profiler on the VM and counted the memory instances. The server keeps the beans in a list, so the GC cant have them, and it turns out that even though memory seems to be running out, orion does not passivate. We told them, and [EMAIL PROTECTED] said thanx and they'd fix it, but they cannot give an estimate of when - we've been waiting for 3 months now. Up to 1.4.5 you could not limit the pool size, so there aint no way to force it to start passivating. Regards Jaco -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Tim Endres Sent: 13 February 2001 23:32 To: Orion-Interest Subject: Re: Garbage collection, out of memory Your GC times are huge because you have provided so much memory. If you reduce the 500MB to 128MB, you will see more GC's, but they will be much shorter. This is a well known optimization issue. Too little memory causes to many GC runs, while too much memory causes GC runs to be too long. You need to experiment to find the best amount of memory to allocate. tim. > Hello > > We are experiencing a garbage collection problem. We are running Orion > 1.4.7 on a Linux 2.4 box. We have been trying the Sun 1.2.2, the Sun 1.3 > and the IBM JVM 1.3. On the Sun 1.3 JVM we have tried normal garbage > collection and also -Xincgc incremental garbage collection. We run with > 500 megabytes of heap space available to Java. > > The system uses lots of EJBs (mainly stateless session but also quite a > few entities and a handful of stateful session beans), and we have JSP > pages which run in the same JVM. > > The system runs very responsively and well, with up to 90 users > simultaneously using it, for up to an hour. Then enormous GCs start > happening which block all activity for up to 180 seconds at a time! The > length and frequency of the freezes vary with the different JVMs but all > are unusable after say an hour of up time. > > The Sun 1.3 in incremental GC mode is the best, and in fact remains stable > and usable until it starts doing a few 9 second GCs from time to time > (comparatively bearable) until we get a "HotSpot internal error" which > stops all processing. > > We are trying all sorts of different things to stop our users getting > upset, like reducing the JSP session timeout to a minimum, and are > currently trying to analyse the code with JProbe to find out how to > minimise unnecessary object creation or memory leaks (stale references to > no longer used objects etc). > > As several list members have already said, it also seems that some beans > are never passivated. > > What can we do to make Orion stop using more and more memory, and not to > cause such outrageous garbage collection cycles? > > Any comments or suggestions would be very much appreciated. > > -- > Thomas Munro <[EMAIL PROTECTED]> > http://www.fullsix.com/ > Fullsix Technology (Paris) > >
Re: Garbage collection, out of memory
seems like i have a similar problem of orion server not passivating a lot of my beans. i'm running orion 1.4.5 on a win2000 box with about 20 entity beans deployed. the database is MySQL. i have a 128MB heap space and i'll get an "out of memory" error after 1 hour or so. any help is appreciated as i need to deploy by 1st march!! - Original Message - From: "Thomas Munro" <[EMAIL PROTECTED]> To: "Orion-Interest" <[EMAIL PROTECTED]> Sent: Wednesday, February 14, 2001 2:29 AM Subject: Garbage collection, out of memory Hello We are experiencing a garbage collection problem. We are running Orion 1.4.7 on a Linux 2.4 box. We have been trying the Sun 1.2.2, the Sun 1.3 and the IBM JVM 1.3. On the Sun 1.3 JVM we have tried normal garbage collection and also -Xincgc incremental garbage collection. We run with 500 megabytes of heap space available to Java. The system uses lots of EJBs (mainly stateless session but also quite a few entities and a handful of stateful session beans), and we have JSP pages which run in the same JVM. The system runs very responsively and well, with up to 90 users simultaneously using it, for up to an hour. Then enormous GCs start happening which block all activity for up to 180 seconds at a time! The length and frequency of the freezes vary with the different JVMs but all are unusable after say an hour of up time. The Sun 1.3 in incremental GC mode is the best, and in fact remains stable and usable until it starts doing a few 9 second GCs from time to time (comparatively bearable) until we get a "HotSpot internal error" which stops all processing. We are trying all sorts of different things to stop our users getting upset, like reducing the JSP session timeout to a minimum, and are currently trying to analyse the code with JProbe to find out how to minimise unnecessary object creation or memory leaks (stale references to no longer used objects etc). As several list members have already said, it also seems that some beans are never passivated. What can we do to make Orion stop using more and more memory, and not to cause such outrageous garbage collection cycles? Any comments or suggestions would be very much appreciated. -- Thomas Munro <[EMAIL PROTECTED]> http://www.fullsix.com/ Fullsix Technology (Paris)
Re: Garbage collection, out of memory
When you deploy your application. Orion will generate an XML file called orion-ejb-jar.xml, if one does not exist. The file is derived from your EJBs. The file can be found buried in the application-deployments directory. You can set some parameters on each EJB you deem appropriate. These parameters are not set in the auto generated file. The first is a "validity-timeout" set to milliseconds. This will passivate the the EJB if not active. The second is a parameter called "max-instances" . This is set to the max number of EJBs of a particular type you want. I am not sure if this is supported yet, but I believe it was supposed to be implemented in the 1.4.7. Hope this help. Let me know what you figure out. -Mike - Original Message - From: "Thomas Munro" <[EMAIL PROTECTED]> To: "Orion-Interest" <[EMAIL PROTECTED]> Sent: Tuesday, February 13, 2001 1:29 PM Subject: Garbage collection, out of memory > Hello > > We are experiencing a garbage collection problem. We are running Orion > 1.4.7 on a Linux 2.4 box. We have been trying the Sun 1.2.2, the Sun 1.3 > and the IBM JVM 1.3. On the Sun 1.3 JVM we have tried normal garbage > collection and also -Xincgc incremental garbage collection. We run with > 500 megabytes of heap space available to Java. > > The system uses lots of EJBs (mainly stateless session but also quite a > few entities and a handful of stateful session beans), and we have JSP > pages which run in the same JVM. > > The system runs very responsively and well, with up to 90 users > simultaneously using it, for up to an hour. Then enormous GCs start > happening which block all activity for up to 180 seconds at a time! The > length and frequency of the freezes vary with the different JVMs but all > are unusable after say an hour of up time. > > The Sun 1.3 in incremental GC mode is the best, and in fact remains stable > and usable until it starts doing a few 9 second GCs from time to time > (comparatively bearable) until we get a "HotSpot internal error" which > stops all processing. > > We are trying all sorts of different things to stop our users getting > upset, like reducing the JSP session timeout to a minimum, and are > currently trying to analyse the code with JProbe to find out how to > minimise unnecessary object creation or memory leaks (stale references to > no longer used objects etc). > > As several list members have already said, it also seems that some beans > are never passivated. > > What can we do to make Orion stop using more and more memory, and not to > cause such outrageous garbage collection cycles? > > Any comments or suggestions would be very much appreciated. > > -- > Thomas Munro <[EMAIL PROTECTED]> > http://www.fullsix.com/ > Fullsix Technology (Paris) > >
Re: Garbage collection, out of memory
Your GC times are huge because you have provided so much memory. If you reduce the 500MB to 128MB, you will see more GC's, but they will be much shorter. This is a well known optimization issue. Too little memory causes to many GC runs, while too much memory causes GC runs to be too long. You need to experiment to find the best amount of memory to allocate. tim. > Hello > > We are experiencing a garbage collection problem. We are running Orion > 1.4.7 on a Linux 2.4 box. We have been trying the Sun 1.2.2, the Sun 1.3 > and the IBM JVM 1.3. On the Sun 1.3 JVM we have tried normal garbage > collection and also -Xincgc incremental garbage collection. We run with > 500 megabytes of heap space available to Java. > > The system uses lots of EJBs (mainly stateless session but also quite a > few entities and a handful of stateful session beans), and we have JSP > pages which run in the same JVM. > > The system runs very responsively and well, with up to 90 users > simultaneously using it, for up to an hour. Then enormous GCs start > happening which block all activity for up to 180 seconds at a time! The > length and frequency of the freezes vary with the different JVMs but all > are unusable after say an hour of up time. > > The Sun 1.3 in incremental GC mode is the best, and in fact remains stable > and usable until it starts doing a few 9 second GCs from time to time > (comparatively bearable) until we get a "HotSpot internal error" which > stops all processing. > > We are trying all sorts of different things to stop our users getting > upset, like reducing the JSP session timeout to a minimum, and are > currently trying to analyse the code with JProbe to find out how to > minimise unnecessary object creation or memory leaks (stale references to > no longer used objects etc). > > As several list members have already said, it also seems that some beans > are never passivated. > > What can we do to make Orion stop using more and more memory, and not to > cause such outrageous garbage collection cycles? > > Any comments or suggestions would be very much appreciated. > > -- > Thomas Munro <[EMAIL PROTECTED]> > http://www.fullsix.com/ > Fullsix Technology (Paris) > >
