You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Maxim Berkultsev <ma...@gmail.com> on 2006/03/29 10:28:44 UTC
VM options to run Geronimo
Hi, all!
I'm trying to make some performance evaluations of Geronimo with a help of
JMeter.
It has appeared relatively simple to get Geronimo out of work. I've tried to
load it with JMeter and a web primitive called **PingServlet2MDBQueue** from
Daytrader bundle. I've created immediate load for 10 virtual users and
unlimited number of requests. Within a minute or two Geronimo stopped
responding to any request logging to console something like
...
18:32:56,180 WARN [ThreadedServer] EXCEPTION
java.lang.OutOfMemoryError
18:32:57,211 WARN [ThreadedServer] EXCEPTION
java.lang.OutOfMemoryError
...
Has someone used any specific VM options to run Geronimo smoothly? (As for
me I've tried starting Geronimo with Java 1.4.2 Hotspot(TM) VM with -server
option enabled).
Any advice or reference could be helpful. Thank you.
--
Best regards,
Maxim Berkultsev, Intel Middleware Products Division
Re: VM options to run Geronimo
Posted by Jeff Genender <jg...@apache.org>.
Cool stuff (or maybe not so cool). The question now is it a memory leak
(likely yes)...and is the leak caused by the container or by Daytrader.
The key now is to get a profiler on it and identify the culprit.
Maxim Berkultsev wrote:
> Hi, Jeff!
>
> With 512M of heap Geronimo has stopped responding in three hours under
> the same initial workload conditions. The console has indicated OOM.
>
> --
> Best regards,
> Maxim Berkultsev, Intel Middleware Products Division
>
>
> 2006/3/29, Jeff Genender wrote:
>
> Did you try upping the memory? Set your environment JAVA_OPTS to:
>
> "-Xms512M -Xmx512M"
>
> Maxim Berkultsev wrote:
> > Hi, all!
> >
> > I'm trying to make some performance evaluations of Geronimo with a
> help
> > of JMeter.
> >
> > It has appeared relatively simple to get Geronimo out of work. I've
> > tried to load it with JMeter and a web primitive called
> > **PingServlet2MDBQueue** from Daytrader bundle. I've created immediate
> > load for 10 virtual users and unlimited number of requests. Within a
> > minute or two Geronimo stopped responding to any request logging to
> > console something like
> >
> > ...
> > 18:32:56,180 WARN [ThreadedServer] EXCEPTION
> > java.lang.OutOfMemoryError
> > 18:32:57,211 WARN [ThreadedServer] EXCEPTION
> > java.lang.OutOfMemoryError
> > ...
> >
> > Has someone used any specific VM options to run Geronimo smoothly? (As
> > for me I've tried starting Geronimo with Java 1.4.2 Hotspot(TM) VM
> with
> > -server option enabled).
> >
> > Any advice or reference could be helpful. Thank you.
> >
> > --
> > Best regards,
> > Maxim Berkultsev, Intel Middleware Products Division
>
Re: VM options to run Geronimo
Posted by Maxim Berkultsev <ma...@gmail.com>.
Hi, Jeff!
With 512M of heap Geronimo has stopped responding in three hours under
the same initial workload conditions. The console has indicated OOM.
--
Best regards,
Maxim Berkultsev, Intel Middleware Products Division
2006/3/29, Jeff Genender wrote:
>
> Did you try upping the memory? Set your environment JAVA_OPTS to:
>
> "-Xms512M -Xmx512M"
>
> Maxim Berkultsev wrote:
> > Hi, all!
> >
> > I'm trying to make some performance evaluations of Geronimo with a help
> > of JMeter.
> >
> > It has appeared relatively simple to get Geronimo out of work. I've
> > tried to load it with JMeter and a web primitive called
> > **PingServlet2MDBQueue** from Daytrader bundle. I've created immediate
> > load for 10 virtual users and unlimited number of requests. Within a
> > minute or two Geronimo stopped responding to any request logging to
> > console something like
> >
> > ...
> > 18:32:56,180 WARN [ThreadedServer] EXCEPTION
> > java.lang.OutOfMemoryError
> > 18:32:57,211 WARN [ThreadedServer] EXCEPTION
> > java.lang.OutOfMemoryError
> > ...
> >
> > Has someone used any specific VM options to run Geronimo smoothly? (As
> > for me I've tried starting Geronimo with Java 1.4.2 Hotspot(TM) VM with
> > -server option enabled).
> >
> > Any advice or reference could be helpful. Thank you.
> >
> > --
> > Best regards,
> > Maxim Berkultsev, Intel Middleware Products Division
Re: VM options to run Geronimo
Posted by Jeff Genender <jg...@apache.org>.
Did you try upping the memory? Set your environment JAVA_OPTS to:
"-Xms512M -Xmx512M"
Maxim Berkultsev wrote:
> Hi, all!
>
> I'm trying to make some performance evaluations of Geronimo with a help
> of JMeter.
>
> It has appeared relatively simple to get Geronimo out of work. I've
> tried to load it with JMeter and a web primitive called
> **PingServlet2MDBQueue** from Daytrader bundle. I've created immediate
> load for 10 virtual users and unlimited number of requests. Within a
> minute or two Geronimo stopped responding to any request logging to
> console something like
>
> ...
> 18:32:56,180 WARN [ThreadedServer] EXCEPTION
> java.lang.OutOfMemoryError
> 18:32:57,211 WARN [ThreadedServer] EXCEPTION
> java.lang.OutOfMemoryError
> ...
>
> Has someone used any specific VM options to run Geronimo smoothly? (As
> for me I've tried starting Geronimo with Java 1.4.2 Hotspot(TM) VM with
> -server option enabled).
>
> Any advice or reference could be helpful. Thank you.
>
> --
> Best regards,
> Maxim Berkultsev, Intel Middleware Products Division
Re: VM options to run Geronimo
Posted by Maxim Berkultsev <ma...@gmail.com>.
Hi, Matt!
Sorry for delay with the response - I had figured out all the issues
you've mentioned. Please see my comments below...
2006/3/31, Matt Hogstrom wrote:
> Hi Maxim,
>
> We need a heap dump to chase this down. We had a leak (identified in the
> release notes) when we shipped. I found that it was about 1MB per hour under
> load on a dual 3.0Ghz Xeon (no hyperthreading).
>
> I was using Derby at the time. I've been changing the tranQL connection manager
> and haven't seen it appear but I haven't specifically done a long run like I
> did before.
>
> It would be helpful to coordinate efforts on what areas your focusing on.
I have a question - do you think if it is reasonable and valuable up
to performance estimations to use Daytrader web primitives as workload
instances for JMeter?
> I think the memory leak would be excellent. Can you tell me a bit about your test
> setup? I have a couple of engineering boxes you guys provided and they are
> outlined in the note you referred to earlier.
I suppose it is a memory leak, maybe the problem is with JMS - here is
the log I've got...
-----------------------
...
Geronimo Application Server started
12:37:34,127 INFO [ActiveMQSession] Caught :java.lang.OutOfMemoryError
java.lang.OutOfMemoryError
12:37:35,655 WARN [ServletHandler] Error for /daytrader/servlet/PingServlet2MDB
Queue
java.lang.OutOfMemoryError
12:37:36,669 WARN [BrokerClientImpl] caught exception consuming packet: PRODUCE
R_INFO: id = 4001 ProducerInfo{ clientId = 'ID:localhost-1990-1144139708721-10
:0' , destination = TradeBrokerQueue, producerId = '13905' , sessionId = '13905'
, startTime = 1144139848263, started = false }
java.lang.OutOfMemoryError
java.lang.OutOfMemoryError
12:37:39,663 WARN [ServletHandler] Error for /daytrader/servlet/PingServlet2MDB
Queue
java.lang.OutOfMemoryError
12:37:42,673 WARN [ServletHandler] Error for /daytrader/servlet/PingServlet2MDB
Queue
java.lang.OutOfMemoryError
12:37:43,640 WARN [ServletHandler] Error for /daytrader/servlet/PingServlet2MDB
Queue
java.lang.OutOfMemoryError
-----------------------
I cannot provide a stack trace - but the problem is simply reproducible.
May be the problem is due to one cannot use PingServlet2MDBQueue for
multiuser load? Somehow I think it is a kind of memory leak. Since
Geronimo accepts the load for a minute or two and then fails with the
log...
>Also, can you do your testing with jRockit ? I think the information
on another
>JVM would be a good thing.
jRockit 1.4.2 does work - no auxiliary VM memory options are
specified! I have not got any OOM problem while running the workload.
> Also, what TZ are you located in? I'm UTC -5 (Raleigh, NC)
I'm GMT+3 (Moscow)
> Also, check us out on Irc irc://irc.freenode.net:6667 Channel #geronimo
Thank you.
--
Best regards,
Maxim Berkultsev, Intel Middleware Products Division
>
> Maxim Berkultsev wrote:
> > Hi, Matt!
> >
> > I've tried
> >
> > java -server -XX:-PrintTenuringDistribution -XX:+PrintGCDetails
> > -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -jar ./bin/server.jar
> >
> > since it seems too long to wait for the problem so I've limited VM with
> > the default heap size. Please see a portion of log below.
> >
> > It looks as if the heap was taken up intensively.
> >
> > For an OutOfMemory problem please see the stack trace further.
> >
> > Best regards,
> > Maxim Berkultsev, Intel Middleware Products Division
> >
> > ------------------
> >
> > .......
> >
> > 535.751: [Tenured[Unloading class
> > sun.reflect.GeneratedSerializationConstructorAccessor461]:
> > 58303K->58303K(58304K), 0.4943219 secs] 64355K->64332K(64832K), [Perm :
> > 31861K->31855K(32000K)] Heap after GC invocations=1056:
> >
> > Heap def new generation total 6528K, used 6028K [0x10010000, 0x10720000,
> > 0x10720000)
> >
> > eden space 5824K, 99% used [0x10010000, 0x105bffd8, 0x105c0000)
> >
> > from space 704K, 29% used [0x10670000, 0x106a3220, 0x10720000)
> >
> > to space 704K, 0% used [0x105c0000, 0x105c0000, 0x10670000)
> >
> > tenured generation total 58304K, used 58303K [0x10720000, 0x14010000,
> > 0x14010000)
> >
> > the space 58304K, 99% used [0x10720000, 0x1400fff8, 0x14010000, 0x14010000)
> >
> > compacting perm gen total 32000K, used 31855K [0x14010000, 0x15f50000,
> > 0x18010000)
> >
> > the space 32000K, 99% used [0x14010000, 0x15f2bdb8, 0x15f2be00, 0x15f50000)}
> > , 0.4963221 secs]
> >
> > 17:10:00,921 WARN [ServletHandler] Error for
> > /daytrader/servlet/PingServlet2MDBQueue java.lang.OutOfMemoryError
> > ------------------
> >
> > 19:42:39,401 ERROR [Log] Error: PingServlet2MDBQueue.doGet(...):exception
> > posting message to TradeBrokerQueue destination
> >
> > 19:42:39,401 ERROR [Log] Error: PingServlet2MDBQueue.doGet(...): error
> >
> > java.util.ConcurrentModificationException
> > java.util.ConcurrentModificationException
> >
> > at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:448)
> >
> > at java.util.AbstractList$Itr.next(AbstractList.java:419)
> >
> > at java.util.AbstractCollection.remove(AbstractCollection.java:254)
> >
> > at org.activemq.TransactionContext.removeSession(TransactionContext.java
> > :116)
> >
> > at org.activemq.ra.RATransactionContext.removeSession(
> > RATransactionContext.java:57)
> >
> > at org.activemq.ActiveMQSession.doClose(ActiveMQSession.java:466)
> >
> > at org.activemq.ActiveMQSession.close(ActiveMQSession.java:447)
> >
> > at org.activemq.ra.JMSSessionProxy.cleanup(JMSSessionProxy.java:87)
> >
> > at org.activemq.ra.JMSSessionProxy.close(JMSSessionProxy.java:76)
> >
> > at org.apache.geronimo.samples.daytrader.web.prims.PingServlet2MDBQueue.
> >
> > doGet(PingServlet2MDBQueue.java:127)
> >
> > at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
> >
> > at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
> >
> > at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
> >
> > at org.apache.geronimo.jetty.JettyServletHolder.handle(
> > JettyServletHolder.java:99)
> >
> > at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(
> > WebApplicationHandler.java:830)
> >
> > at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170)
> >
> > at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(
> > WebApplicationHandler.java:821)
> >
> > at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(
> > WebApplicationHandler.java:471)
> >
> > at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568)
> >
> > at org.mortbay.http.HttpContext.handle(HttpContext.java:1530)
> >
> > at org.mortbay.jetty.servlet.WebApplicationContext.handle(
> > WebApplicationContext.java:633)
> >
> > at org.mortbay.http.HttpContext.handle(HttpContext.java:1482)
> >
> > at org.mortbay.http.HttpServer.service(HttpServer.java:909)
> >
> > at org.mortbay.http.HttpConnection.service(HttpConnection.java:816)
> >
> > at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982)
> >
> > at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833)
> >
> > at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244)
> >
> > at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
> >
> > at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
> >
> > java.util.ConcurrentModificationException
> >
> > at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:448)
> >
> > at java.util.AbstractList$Itr.next(AbstractList.java:419)
> >
> > at java.util.AbstractCollection.remove(AbstractCollection.java:254)
> >
> > at org.activemq.TransactionContext.removeSession(TransactionContext.java
> > :116)
> >
> > at org.activemq.ra.RATransactionContext.removeSession(
> > RATransactionContext.java:57)
> >
> > at org.activemq.ActiveMQSession.doClose(ActiveMQSession.java:466)
> >
> > at org.activemq.ActiveMQSession.close(ActiveMQSession.java:447)
> >
> > at org.activemq.ra.JMSSessionProxy.cleanup(JMSSessionProxy.java:87)
> >
> > at org.activemq.ra.JMSSessionProxy.close(JMSSessionProxy.java:76)
> >
> > at org.apache.geronimo.samples.daytrader.web.prims.PingServlet2MDBQueue:
> >
> > doGet(PingServlet2MDBQueue.java:127)
> >
> > at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
> >
> > at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
> >
> > at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
> >
> > at org.apache.geronimo.jetty.JettyServletHolder.handle(
> > JettyServletHolder.java:99)
> >
> > at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(
> > WebApplicationHandler.java:830)
> >
> > at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170)
> >
> > at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(
> > WebApplicationHandler.java:821)
> >
> > at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(
> > WebApplicationHandler.java:471)
> >
> > at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568)
> >
> > at org.mortbay.http.HttpContext.handle(HttpContext.java:1530)
> >
> > at org.mortbay.jetty.servlet.WebApplicationContext.handle(
> > WebApplicationContext.java:633)
> >
> > at org.mortbay.http.HttpContext.handle(HttpContext.java:1482)
> >
> > at org.mortbay.http.HttpServer.service(HttpServer.java:909)
> >
> > at org.mortbay.http.HttpConnection.service(HttpConnection.java:816)
> >
> > at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982)
> >
> > at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833)
> >
> > at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244)
> >
> > at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
> >
> > at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
> >
> > 19:43:29,178 WARN [ServletHandler] Error for
> > /daytrader/servlet/PingServlet2MDBQueue
> >
> > java.lang.OutOfMemoryError
> >
> > 19:43:30,365 WARN [HttpConnection] GET
> > /daytrader/servlet/PingServlet2MDBQueue HTTP/1.1
> >
> > java.lang.OutOfMemoryError
> >
> > 19:43:31,412 WARN [JournalMessageStore] Message could not be added to long
> > term store: null
> >
> > java.lang.OutOfMemoryError
> >
> > ----------
> >
> >
> > 2006/3/29, Matt Hogstrom wrote:
> >
> >>In the tests I'm running I use the following:
> >>
> >>java -server -Xmx2048m -Xms2048m -XX:-PrintTenuringDistribution
> >>-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -jar
> >>/home/hogstrom/geronimo-1.0/bin/server.jar
> >>
> >>I have not played too much with tuning the tenuring for the eden
> >>sizes. Do you
> >>have a stack trace indicating where you failed? OutOfMemory could mean
> >>several
> >>things.
> >>
> >>Maxim Berkultsev wrote:
> >>
> >>>Hi, all!
> >>>
> >>>I'm trying to make some performance evaluations of Geronimo with a help
> >>
> >>of
> >>
> >>>JMeter.
> >>>
> >>>It has appeared relatively simple to get Geronimo out of work. I've
> >>
> >>tried to
> >>
> >>>load it with JMeter and a web primitive called **PingServlet2MDBQueue**
> >>
> >>from
> >>
> >>>Daytrader bundle. I've created immediate load for 10 virtual users and
> >>>unlimited number of requests. Within a minute or two Geronimo stopped
> >>>responding to any request logging to console something like
> >>>...
> >>>18:32:56,180 WARN [ThreadedServer] EXCEPTION
> >>>java.lang.OutOfMemoryError
> >>>18:32:57,211 WARN [ThreadedServer] EXCEPTION
> >>>java.lang.OutOfMemoryError
> >>>...
> >>>
> >>>Has someone used any specific VM options to run Geronimo smoothly? (As
> >>
> >>for
> >>
> >>>me I've tried starting Geronimo with Java 1.4.2 Hotspot(TM) VM with
> >>
> >>-server
> >>
> >>>option enabled).
> >>>
> >>>Any advice or reference could be helpful. Thank you.
> >>>--
> >>>Best regards,
> >>>Maxim Berkultsev, Intel Middleware Products Division
> >>>
> >>
> >
>
Re: VM options to run Geronimo
Posted by Matt Hogstrom <ma...@hogstrom.org>.
Hi Maxim,
We need a heap dump to chase this down. We had a leak (identified in the
release notes) when we shipped. I found that it was about 1MB per hour under
load on a dual 3.0Ghz Xeon (no hyperthreading).
I was using Derby at the time. I've been changing the tranQL connection manager
and haven't seen it appear but I haven't specifically done a long run like I
did before.
It would be helpful to coordinate efforts on what areas your focusing on. I
think the memory leak would be excellent. Can you tell me a bit about your test
setup? I have a couple of engineering boxes you guys provided and they are
outlined in the note you referred to earlier.
Also, can you do your testing with jRockit ? I think the information on another
JVM would be a good thing.
Also, what TZ are you located in? I'm UTC -5 (Raleigh, NC)
Also, check us out on Irc irc://irc.freenode.net:6667 Channel #geronimo
Maxim Berkultsev wrote:
> Hi, Matt!
>
> I've tried
>
> java -server -XX:-PrintTenuringDistribution -XX:+PrintGCDetails
> -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -jar ./bin/server.jar
>
> since it seems too long to wait for the problem so I've limited VM with
> the default heap size. Please see a portion of log below.
>
> It looks as if the heap was taken up intensively.
>
> For an OutOfMemory problem please see the stack trace further.
>
> Best regards,
> Maxim Berkultsev, Intel Middleware Products Division
>
> ------------------
>
> .......
>
> 535.751: [Tenured[Unloading class
> sun.reflect.GeneratedSerializationConstructorAccessor461]:
> 58303K->58303K(58304K), 0.4943219 secs] 64355K->64332K(64832K), [Perm :
> 31861K->31855K(32000K)] Heap after GC invocations=1056:
>
> Heap def new generation total 6528K, used 6028K [0x10010000, 0x10720000,
> 0x10720000)
>
> eden space 5824K, 99% used [0x10010000, 0x105bffd8, 0x105c0000)
>
> from space 704K, 29% used [0x10670000, 0x106a3220, 0x10720000)
>
> to space 704K, 0% used [0x105c0000, 0x105c0000, 0x10670000)
>
> tenured generation total 58304K, used 58303K [0x10720000, 0x14010000,
> 0x14010000)
>
> the space 58304K, 99% used [0x10720000, 0x1400fff8, 0x14010000, 0x14010000)
>
> compacting perm gen total 32000K, used 31855K [0x14010000, 0x15f50000,
> 0x18010000)
>
> the space 32000K, 99% used [0x14010000, 0x15f2bdb8, 0x15f2be00, 0x15f50000)}
> , 0.4963221 secs]
>
> 17:10:00,921 WARN [ServletHandler] Error for
> /daytrader/servlet/PingServlet2MDBQueue java.lang.OutOfMemoryError
> ------------------
>
> 19:42:39,401 ERROR [Log] Error: PingServlet2MDBQueue.doGet(...):exception
> posting message to TradeBrokerQueue destination
>
> 19:42:39,401 ERROR [Log] Error: PingServlet2MDBQueue.doGet(...): error
>
> java.util.ConcurrentModificationException
> java.util.ConcurrentModificationException
>
> at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:448)
>
> at java.util.AbstractList$Itr.next(AbstractList.java:419)
>
> at java.util.AbstractCollection.remove(AbstractCollection.java:254)
>
> at org.activemq.TransactionContext.removeSession(TransactionContext.java
> :116)
>
> at org.activemq.ra.RATransactionContext.removeSession(
> RATransactionContext.java:57)
>
> at org.activemq.ActiveMQSession.doClose(ActiveMQSession.java:466)
>
> at org.activemq.ActiveMQSession.close(ActiveMQSession.java:447)
>
> at org.activemq.ra.JMSSessionProxy.cleanup(JMSSessionProxy.java:87)
>
> at org.activemq.ra.JMSSessionProxy.close(JMSSessionProxy.java:76)
>
> at org.apache.geronimo.samples.daytrader.web.prims.PingServlet2MDBQueue.
>
> doGet(PingServlet2MDBQueue.java:127)
>
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
>
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
>
> at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
>
> at org.apache.geronimo.jetty.JettyServletHolder.handle(
> JettyServletHolder.java:99)
>
> at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(
> WebApplicationHandler.java:830)
>
> at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170)
>
> at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(
> WebApplicationHandler.java:821)
>
> at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(
> WebApplicationHandler.java:471)
>
> at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568)
>
> at org.mortbay.http.HttpContext.handle(HttpContext.java:1530)
>
> at org.mortbay.jetty.servlet.WebApplicationContext.handle(
> WebApplicationContext.java:633)
>
> at org.mortbay.http.HttpContext.handle(HttpContext.java:1482)
>
> at org.mortbay.http.HttpServer.service(HttpServer.java:909)
>
> at org.mortbay.http.HttpConnection.service(HttpConnection.java:816)
>
> at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982)
>
> at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833)
>
> at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244)
>
> at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
>
> at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
>
> java.util.ConcurrentModificationException
>
> at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:448)
>
> at java.util.AbstractList$Itr.next(AbstractList.java:419)
>
> at java.util.AbstractCollection.remove(AbstractCollection.java:254)
>
> at org.activemq.TransactionContext.removeSession(TransactionContext.java
> :116)
>
> at org.activemq.ra.RATransactionContext.removeSession(
> RATransactionContext.java:57)
>
> at org.activemq.ActiveMQSession.doClose(ActiveMQSession.java:466)
>
> at org.activemq.ActiveMQSession.close(ActiveMQSession.java:447)
>
> at org.activemq.ra.JMSSessionProxy.cleanup(JMSSessionProxy.java:87)
>
> at org.activemq.ra.JMSSessionProxy.close(JMSSessionProxy.java:76)
>
> at org.apache.geronimo.samples.daytrader.web.prims.PingServlet2MDBQueue:
>
> doGet(PingServlet2MDBQueue.java:127)
>
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
>
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
>
> at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
>
> at org.apache.geronimo.jetty.JettyServletHolder.handle(
> JettyServletHolder.java:99)
>
> at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(
> WebApplicationHandler.java:830)
>
> at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170)
>
> at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(
> WebApplicationHandler.java:821)
>
> at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(
> WebApplicationHandler.java:471)
>
> at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568)
>
> at org.mortbay.http.HttpContext.handle(HttpContext.java:1530)
>
> at org.mortbay.jetty.servlet.WebApplicationContext.handle(
> WebApplicationContext.java:633)
>
> at org.mortbay.http.HttpContext.handle(HttpContext.java:1482)
>
> at org.mortbay.http.HttpServer.service(HttpServer.java:909)
>
> at org.mortbay.http.HttpConnection.service(HttpConnection.java:816)
>
> at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982)
>
> at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833)
>
> at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244)
>
> at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
>
> at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
>
> 19:43:29,178 WARN [ServletHandler] Error for
> /daytrader/servlet/PingServlet2MDBQueue
>
> java.lang.OutOfMemoryError
>
> 19:43:30,365 WARN [HttpConnection] GET
> /daytrader/servlet/PingServlet2MDBQueue HTTP/1.1
>
> java.lang.OutOfMemoryError
>
> 19:43:31,412 WARN [JournalMessageStore] Message could not be added to long
> term store: null
>
> java.lang.OutOfMemoryError
>
> ----------
>
>
> 2006/3/29, Matt Hogstrom wrote:
>
>>In the tests I'm running I use the following:
>>
>>java -server -Xmx2048m -Xms2048m -XX:-PrintTenuringDistribution
>>-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -jar
>>/home/hogstrom/geronimo-1.0/bin/server.jar
>>
>>I have not played too much with tuning the tenuring for the eden
>>sizes. Do you
>>have a stack trace indicating where you failed? OutOfMemory could mean
>>several
>>things.
>>
>>Maxim Berkultsev wrote:
>>
>>>Hi, all!
>>>
>>>I'm trying to make some performance evaluations of Geronimo with a help
>>
>>of
>>
>>>JMeter.
>>>
>>>It has appeared relatively simple to get Geronimo out of work. I've
>>
>>tried to
>>
>>>load it with JMeter and a web primitive called **PingServlet2MDBQueue**
>>
>>from
>>
>>>Daytrader bundle. I've created immediate load for 10 virtual users and
>>>unlimited number of requests. Within a minute or two Geronimo stopped
>>>responding to any request logging to console something like
>>>...
>>>18:32:56,180 WARN [ThreadedServer] EXCEPTION
>>>java.lang.OutOfMemoryError
>>>18:32:57,211 WARN [ThreadedServer] EXCEPTION
>>>java.lang.OutOfMemoryError
>>>...
>>>
>>>Has someone used any specific VM options to run Geronimo smoothly? (As
>>
>>for
>>
>>>me I've tried starting Geronimo with Java 1.4.2 Hotspot(TM) VM with
>>
>>-server
>>
>>>option enabled).
>>>
>>>Any advice or reference could be helpful. Thank you.
>>>--
>>>Best regards,
>>>Maxim Berkultsev, Intel Middleware Products Division
>>>
>>
>
Re: VM options to run Geronimo
Posted by Maxim Berkultsev <ma...@gmail.com>.
Hi, Matt!
I've tried
java -server -XX:-PrintTenuringDistribution -XX:+PrintGCDetails
-XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -jar ./bin/server.jar
since it seems too long to wait for the problem so I've limited VM with
the default heap size. Please see a portion of log below.
It looks as if the heap was taken up intensively.
For an OutOfMemory problem please see the stack trace further.
Best regards,
Maxim Berkultsev, Intel Middleware Products Division
------------------
.......
535.751: [Tenured[Unloading class
sun.reflect.GeneratedSerializationConstructorAccessor461]:
58303K->58303K(58304K), 0.4943219 secs] 64355K->64332K(64832K), [Perm :
31861K->31855K(32000K)] Heap after GC invocations=1056:
Heap def new generation total 6528K, used 6028K [0x10010000, 0x10720000,
0x10720000)
eden space 5824K, 99% used [0x10010000, 0x105bffd8, 0x105c0000)
from space 704K, 29% used [0x10670000, 0x106a3220, 0x10720000)
to space 704K, 0% used [0x105c0000, 0x105c0000, 0x10670000)
tenured generation total 58304K, used 58303K [0x10720000, 0x14010000,
0x14010000)
the space 58304K, 99% used [0x10720000, 0x1400fff8, 0x14010000, 0x14010000)
compacting perm gen total 32000K, used 31855K [0x14010000, 0x15f50000,
0x18010000)
the space 32000K, 99% used [0x14010000, 0x15f2bdb8, 0x15f2be00, 0x15f50000)}
, 0.4963221 secs]
17:10:00,921 WARN [ServletHandler] Error for
/daytrader/servlet/PingServlet2MDBQueue java.lang.OutOfMemoryError
------------------
19:42:39,401 ERROR [Log] Error: PingServlet2MDBQueue.doGet(...):exception
posting message to TradeBrokerQueue destination
19:42:39,401 ERROR [Log] Error: PingServlet2MDBQueue.doGet(...): error
java.util.ConcurrentModificationException
java.util.ConcurrentModificationException
at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:448)
at java.util.AbstractList$Itr.next(AbstractList.java:419)
at java.util.AbstractCollection.remove(AbstractCollection.java:254)
at org.activemq.TransactionContext.removeSession(TransactionContext.java
:116)
at org.activemq.ra.RATransactionContext.removeSession(
RATransactionContext.java:57)
at org.activemq.ActiveMQSession.doClose(ActiveMQSession.java:466)
at org.activemq.ActiveMQSession.close(ActiveMQSession.java:447)
at org.activemq.ra.JMSSessionProxy.cleanup(JMSSessionProxy.java:87)
at org.activemq.ra.JMSSessionProxy.close(JMSSessionProxy.java:76)
at org.apache.geronimo.samples.daytrader.web.prims.PingServlet2MDBQueue.
doGet(PingServlet2MDBQueue.java:127)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
at org.apache.geronimo.jetty.JettyServletHolder.handle(
JettyServletHolder.java:99)
at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(
WebApplicationHandler.java:830)
at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170)
at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(
WebApplicationHandler.java:821)
at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(
WebApplicationHandler.java:471)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1530)
at org.mortbay.jetty.servlet.WebApplicationContext.handle(
WebApplicationContext.java:633)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1482)
at org.mortbay.http.HttpServer.service(HttpServer.java:909)
at org.mortbay.http.HttpConnection.service(HttpConnection.java:816)
at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982)
at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833)
at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244)
at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
java.util.ConcurrentModificationException
at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:448)
at java.util.AbstractList$Itr.next(AbstractList.java:419)
at java.util.AbstractCollection.remove(AbstractCollection.java:254)
at org.activemq.TransactionContext.removeSession(TransactionContext.java
:116)
at org.activemq.ra.RATransactionContext.removeSession(
RATransactionContext.java:57)
at org.activemq.ActiveMQSession.doClose(ActiveMQSession.java:466)
at org.activemq.ActiveMQSession.close(ActiveMQSession.java:447)
at org.activemq.ra.JMSSessionProxy.cleanup(JMSSessionProxy.java:87)
at org.activemq.ra.JMSSessionProxy.close(JMSSessionProxy.java:76)
at org.apache.geronimo.samples.daytrader.web.prims.PingServlet2MDBQueue:
doGet(PingServlet2MDBQueue.java:127)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
at org.apache.geronimo.jetty.JettyServletHolder.handle(
JettyServletHolder.java:99)
at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(
WebApplicationHandler.java:830)
at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170)
at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(
WebApplicationHandler.java:821)
at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(
WebApplicationHandler.java:471)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1530)
at org.mortbay.jetty.servlet.WebApplicationContext.handle(
WebApplicationContext.java:633)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1482)
at org.mortbay.http.HttpServer.service(HttpServer.java:909)
at org.mortbay.http.HttpConnection.service(HttpConnection.java:816)
at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982)
at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833)
at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244)
at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
19:43:29,178 WARN [ServletHandler] Error for
/daytrader/servlet/PingServlet2MDBQueue
java.lang.OutOfMemoryError
19:43:30,365 WARN [HttpConnection] GET
/daytrader/servlet/PingServlet2MDBQueue HTTP/1.1
java.lang.OutOfMemoryError
19:43:31,412 WARN [JournalMessageStore] Message could not be added to long
term store: null
java.lang.OutOfMemoryError
----------
2006/3/29, Matt Hogstrom wrote:
>
> In the tests I'm running I use the following:
>
> java -server -Xmx2048m -Xms2048m -XX:-PrintTenuringDistribution
> -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -jar
> /home/hogstrom/geronimo-1.0/bin/server.jar
>
> I have not played too much with tuning the tenuring for the eden
> sizes. Do you
> have a stack trace indicating where you failed? OutOfMemory could mean
> several
> things.
>
> Maxim Berkultsev wrote:
> > Hi, all!
> >
> > I'm trying to make some performance evaluations of Geronimo with a help
> of
> > JMeter.
> >
> > It has appeared relatively simple to get Geronimo out of work. I've
> tried to
> > load it with JMeter and a web primitive called **PingServlet2MDBQueue**
> from
> > Daytrader bundle. I've created immediate load for 10 virtual users and
> > unlimited number of requests. Within a minute or two Geronimo stopped
> > responding to any request logging to console something like
> > ...
> > 18:32:56,180 WARN [ThreadedServer] EXCEPTION
> > java.lang.OutOfMemoryError
> > 18:32:57,211 WARN [ThreadedServer] EXCEPTION
> > java.lang.OutOfMemoryError
> > ...
> >
> > Has someone used any specific VM options to run Geronimo smoothly? (As
> for
> > me I've tried starting Geronimo with Java 1.4.2 Hotspot(TM) VM with
> -server
> > option enabled).
> >
> > Any advice or reference could be helpful. Thank you.
> > --
> > Best regards,
> > Maxim Berkultsev, Intel Middleware Products Division
> >
>
Re: VM options to run Geronimo
Posted by Rajiv M <rm...@gmail.com>.
Hello,
Assuming the tests were done on Win 32.
Windows OS provides each application with its own 32-bit (4GB) address
space. The lower 2GB is *'local'* to the application, which is also referred
to as the *user address space*, while, the upper 2GB contains (read-only)
windows code is shared by all applications, also referred to as *Kernel
address space*. Applications cannot access the 'local' memory part (i.e.,
user address space) of other applications.
As all other applications, the Java process also gets a 2GB user-address
space to use. On Windows, kernel DLLs (such as KERNEL32.dll, msvcrt.dll are
placed somewhere in the 0x70000000 part of the address space in both the
2GB, which means that the maximum contiguous space we can get for Java heap
is less than 2GB, assuming we have no other DLLs
However, the JVM also uses DLLs to interact with windows, drivers and other
applications on the system. Those DLLs are loaded (mapped) in the 2GB user
address space of the JVM. Loading those DLLs in the empty 2GB user-address
space divides up the remaining space. This means the largest possible
contiguous single block of memory only gets smaller as more and more DLLs
are being used by the JVM and the application.
Further, a Java application can also involve other products such as
Websphere, DB2 etc. These products will have their own dlls, and their own
preferred load addresses. So this will further diminish the contiguous space
available for Java heap
So finally ending up in <2GB on a 4GB phyisical memory!!
And so, when 2048 max heap is set and JVM can expand heap only upto < 2 GB,
this potentially causes a memory leak ending in OOM.
I agree that monitoring the GC output is the best way to deduce the cause of
OOM.
~rajiv
On 3/30/06, Calvin Austin <ca...@spikesource.com> wrote:
>
> I think it really depends on how much memory you have, many of the
> specjbb/specjappserver results are run on 32bit machines with 4GB ram
> setting -Xmx2048m -Xms2048m is fine. As Matt points out there is more
> than one out of memory condition. From memory I think 1.4.2 server had
> a max permsize of 64mb so that is one candidate -XX:MaxPermSize=128m
>
> If you are using 1.4.2 hotspot you can also use the free visualgc tool.
> It will automatically detect a running jvm and show what the gc is doing
> http://java.sun.com/performance/jvmstat/
>
> regards
> calvin
>
> Rajiv M wrote:
>
> > I mean -Xms=-Xmx is a bad setting
> > ~rajiv
> >
> >
> > On 3/29/06, *Rajiv M* <rmadassery77@gmail.com
> > <ma...@gmail.com>> wrote:
> >
> > Hello,
> > -Xmx2048m -Xms2048m - this is a very bad setting. this will induce
> > fragmentation of java heap, which means heap will fail to allot
> > contiguous memory for a large object allocation (greater than 7 MB
> > is considered large). This would subsequently end in an OOM.
> >
> > Ideally -Xms256 and -Xmx1024 could be tried.
> >
> > ~rajiv
> >
> > On 3/29/06, *Jeff Genender* <jgenender@apache.org
> > <ma...@apache.org>> wrote:
> >
> > Whew 2G of Memory!!! Nice!!
> >
> > Matt Hogstrom wrote:
> >> In the tests I'm running I use the following:
> >>
> >> java -server -Xmx2048m -Xms2048m -XX:-PrintTenuringDistribution
> >> -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC
> > -jar
> >> /home/hogstrom/geronimo-1.0/bin/server.jar
> >>
> >> I have not played too much with tuning the tenuring for the
> > eden sizes.
> >> Do you have a stack trace indicating where you
> > failed? OutOfMemory
> >> could mean several things.
> >>
> >> Maxim Berkultsev wrote:
> >>> Hi, all!
> >>>
> >>> I'm trying to make some performance evaluations of Geronimo
> > with a
> >>> help of
> >>> JMeter.
> >>>
> >>> It has appeared relatively simple to get Geronimo out of
> > work. I've
> >>> tried to
> >>> load it with JMeter and a web primitive called
> >>> **PingServlet2MDBQueue** from
> >>> Daytrader bundle. I've created immediate load for 10 virtual
> > users and
> >>> unlimited number of requests. Within a minute or two
> > Geronimo stopped
> >>> responding to any request logging to console something like
> >>> ...
> >>> 18:32:56,180 WARN [ThreadedServer] EXCEPTION
> >>> java.lang.OutOfMemoryError
> >>> 18:32:57,211 WARN [ThreadedServer] EXCEPTION
> >>> java.lang.OutOfMemoryError
> >>> ...
> >>>
> >>> Has someone used any specific VM options to run Geronimo
> > smoothly? (As
> >>> for
> >>> me I've tried starting Geronimo with Java 1.4.2 Hotspot(TM)
> > VM with
> >>> -server
> >>> option enabled).
> >>>
> >>> Any advice or reference could be helpful. Thank you.
> >>> --
> >>> Best regards,
> >>> Maxim Berkultsev, Intel Middleware Products Division
> >>>
> >
> >
> >
> >
> > --
> > ~~~Truth is out there.~~~
> >
> >
> >
> >
> > --
> > ~~~Truth is out there.~~~
>
>
>
--
~~~Truth is out there.~~~
Re: VM options to run Geronimo
Posted by Calvin Austin <ca...@spikesource.com>.
I think it really depends on how much memory you have, many of the
specjbb/specjappserver results are run on 32bit machines with 4GB ram
setting -Xmx2048m -Xms2048m is fine. As Matt points out there is more
than one out of memory condition. From memory I think 1.4.2 server had
a max permsize of 64mb so that is one candidate -XX:MaxPermSize=128m
If you are using 1.4.2 hotspot you can also use the free visualgc tool.
It will automatically detect a running jvm and show what the gc is doing
http://java.sun.com/performance/jvmstat/
regards
calvin
Rajiv M wrote:
> I mean -Xms=-Xmx is a bad setting
> ~rajiv
>
>
> On 3/29/06, *Rajiv M* <rmadassery77@gmail.com
> <ma...@gmail.com>> wrote:
>
> Hello,
> -Xmx2048m -Xms2048m - this is a very bad setting. this will induce
> fragmentation of java heap, which means heap will fail to allot
> contiguous memory for a large object allocation (greater than 7 MB
> is considered large). This would subsequently end in an OOM.
>
> Ideally -Xms256 and -Xmx1024 could be tried.
>
> ~rajiv
>
> On 3/29/06, *Jeff Genender* <jgenender@apache.org
> <ma...@apache.org>> wrote:
>
> Whew 2G of Memory!!! Nice!!
>
> Matt Hogstrom wrote:
>> In the tests I'm running I use the following:
>>
>> java -server -Xmx2048m -Xms2048m -XX:-PrintTenuringDistribution
>> -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC
> -jar
>> /home/hogstrom/geronimo-1.0/bin/server.jar
>>
>> I have not played too much with tuning the tenuring for the
> eden sizes.
>> Do you have a stack trace indicating where you
> failed? OutOfMemory
>> could mean several things.
>>
>> Maxim Berkultsev wrote:
>>> Hi, all!
>>>
>>> I'm trying to make some performance evaluations of Geronimo
> with a
>>> help of
>>> JMeter.
>>>
>>> It has appeared relatively simple to get Geronimo out of
> work. I've
>>> tried to
>>> load it with JMeter and a web primitive called
>>> **PingServlet2MDBQueue** from
>>> Daytrader bundle. I've created immediate load for 10 virtual
> users and
>>> unlimited number of requests. Within a minute or two
> Geronimo stopped
>>> responding to any request logging to console something like
>>> ...
>>> 18:32:56,180 WARN [ThreadedServer] EXCEPTION
>>> java.lang.OutOfMemoryError
>>> 18:32:57,211 WARN [ThreadedServer] EXCEPTION
>>> java.lang.OutOfMemoryError
>>> ...
>>>
>>> Has someone used any specific VM options to run Geronimo
> smoothly? (As
>>> for
>>> me I've tried starting Geronimo with Java 1.4.2 Hotspot(TM)
> VM with
>>> -server
>>> option enabled).
>>>
>>> Any advice or reference could be helpful. Thank you.
>>> --
>>> Best regards,
>>> Maxim Berkultsev, Intel Middleware Products Division
>>>
>
>
>
>
> --
> ~~~Truth is out there.~~~
>
>
>
>
> --
> ~~~Truth is out there.~~~
Re: VM options to run Geronimo
Posted by Rajiv M <rm...@gmail.com>.
I mean -Xms=-Xmx is a bad setting
~rajiv
On 3/29/06, Rajiv M <rm...@gmail.com> wrote:
>
> Hello,
> -Xmx2048m -Xms2048m - this is a very bad setting. this will induce
> fragmentation of java heap, which means heap will fail to allot contiguous
> memory for a large object allocation (greater than 7 MB is considered
> large). This would subsequently end in an OOM.
>
> Ideally -Xms256 and -Xmx1024 could be tried.
>
> ~rajiv
>
> On 3/29/06, Jeff Genender <jg...@apache.org> wrote:
> >
> > Whew 2G of Memory!!! Nice!!
> >
> > Matt Hogstrom wrote:
> > > In the tests I'm running I use the following:
> > >
> > > java -server -Xmx2048m -Xms2048m -XX:-PrintTenuringDistribution
> > > -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -jar
> > > /home/hogstrom/geronimo-1.0/bin/server.jar
> > >
> > > I have not played too much with tuning the tenuring for the eden
> > sizes.
> > > Do you have a stack trace indicating where you failed? OutOfMemory
> > > could mean several things.
> > >
> > > Maxim Berkultsev wrote:
> > >> Hi, all!
> > >>
> > >> I'm trying to make some performance evaluations of Geronimo with a
> > >> help of
> > >> JMeter.
> > >>
> > >> It has appeared relatively simple to get Geronimo out of work. I've
> > >> tried to
> > >> load it with JMeter and a web primitive called
> > >> **PingServlet2MDBQueue** from
> > >> Daytrader bundle. I've created immediate load for 10 virtual users
> > and
> > >> unlimited number of requests. Within a minute or two Geronimo stopped
> > >> responding to any request logging to console something like
> > >> ...
> > >> 18:32:56,180 WARN [ThreadedServer] EXCEPTION
> > >> java.lang.OutOfMemoryError
> > >> 18:32:57,211 WARN [ThreadedServer] EXCEPTION
> > >> java.lang.OutOfMemoryError
> > >> ...
> > >>
> > >> Has someone used any specific VM options to run Geronimo smoothly?
> > (As
> > >> for
> > >> me I've tried starting Geronimo with Java 1.4.2 Hotspot(TM) VM with
> > >> -server
> > >> option enabled).
> > >>
> > >> Any advice or reference could be helpful. Thank you.
> > >> --
> > >> Best regards,
> > >> Maxim Berkultsev, Intel Middleware Products Division
> > >>
> >
>
>
>
> --
> ~~~Truth is out there.~~~
>
--
~~~Truth is out there.~~~
Re: VM options to run Geronimo
Posted by Rajiv M <rm...@gmail.com>.
Hello,
-Xmx2048m -Xms2048m - this is a very bad setting. this will induce
fragmentation of java heap, which means heap will fail to allot contiguous
memory for a large object allocation (greater than 7 MB is considered
large). This would subsequently end in an OOM.
Ideally -Xms256 and -Xmx1024 could be tried.
~rajiv
On 3/29/06, Jeff Genender <jg...@apache.org> wrote:
>
> Whew 2G of Memory!!! Nice!!
>
> Matt Hogstrom wrote:
> > In the tests I'm running I use the following:
> >
> > java -server -Xmx2048m -Xms2048m -XX:-PrintTenuringDistribution
> > -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -jar
> > /home/hogstrom/geronimo-1.0/bin/server.jar
> >
> > I have not played too much with tuning the tenuring for the eden sizes.
> > Do you have a stack trace indicating where you failed? OutOfMemory
> > could mean several things.
> >
> > Maxim Berkultsev wrote:
> >> Hi, all!
> >>
> >> I'm trying to make some performance evaluations of Geronimo with a
> >> help of
> >> JMeter.
> >>
> >> It has appeared relatively simple to get Geronimo out of work. I've
> >> tried to
> >> load it with JMeter and a web primitive called
> >> **PingServlet2MDBQueue** from
> >> Daytrader bundle. I've created immediate load for 10 virtual users and
> >> unlimited number of requests. Within a minute or two Geronimo stopped
> >> responding to any request logging to console something like
> >> ...
> >> 18:32:56,180 WARN [ThreadedServer] EXCEPTION
> >> java.lang.OutOfMemoryError
> >> 18:32:57,211 WARN [ThreadedServer] EXCEPTION
> >> java.lang.OutOfMemoryError
> >> ...
> >>
> >> Has someone used any specific VM options to run Geronimo smoothly? (As
> >> for
> >> me I've tried starting Geronimo with Java 1.4.2 Hotspot(TM) VM with
> >> -server
> >> option enabled).
> >>
> >> Any advice or reference could be helpful. Thank you.
> >> --
> >> Best regards,
> >> Maxim Berkultsev, Intel Middleware Products Division
> >>
>
--
~~~Truth is out there.~~~
Re: VM options to run Geronimo
Posted by Jeff Genender <jg...@apache.org>.
Whew 2G of Memory!!! Nice!!
Matt Hogstrom wrote:
> In the tests I'm running I use the following:
>
> java -server -Xmx2048m -Xms2048m -XX:-PrintTenuringDistribution
> -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -jar
> /home/hogstrom/geronimo-1.0/bin/server.jar
>
> I have not played too much with tuning the tenuring for the eden sizes.
> Do you have a stack trace indicating where you failed? OutOfMemory
> could mean several things.
>
> Maxim Berkultsev wrote:
>> Hi, all!
>>
>> I'm trying to make some performance evaluations of Geronimo with a
>> help of
>> JMeter.
>>
>> It has appeared relatively simple to get Geronimo out of work. I've
>> tried to
>> load it with JMeter and a web primitive called
>> **PingServlet2MDBQueue** from
>> Daytrader bundle. I've created immediate load for 10 virtual users and
>> unlimited number of requests. Within a minute or two Geronimo stopped
>> responding to any request logging to console something like
>> ...
>> 18:32:56,180 WARN [ThreadedServer] EXCEPTION
>> java.lang.OutOfMemoryError
>> 18:32:57,211 WARN [ThreadedServer] EXCEPTION
>> java.lang.OutOfMemoryError
>> ...
>>
>> Has someone used any specific VM options to run Geronimo smoothly? (As
>> for
>> me I've tried starting Geronimo with Java 1.4.2 Hotspot(TM) VM with
>> -server
>> option enabled).
>>
>> Any advice or reference could be helpful. Thank you.
>> --
>> Best regards,
>> Maxim Berkultsev, Intel Middleware Products Division
>>
Re: VM options to run Geronimo
Posted by Matt Hogstrom <ma...@hogstrom.org>.
In the tests I'm running I use the following:
java -server -Xmx2048m -Xms2048m -XX:-PrintTenuringDistribution
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -jar
/home/hogstrom/geronimo-1.0/bin/server.jar
I have not played too much with tuning the tenuring for the eden sizes. Do you
have a stack trace indicating where you failed? OutOfMemory could mean several
things.
Maxim Berkultsev wrote:
> Hi, all!
>
> I'm trying to make some performance evaluations of Geronimo with a help of
> JMeter.
>
> It has appeared relatively simple to get Geronimo out of work. I've tried to
> load it with JMeter and a web primitive called **PingServlet2MDBQueue** from
> Daytrader bundle. I've created immediate load for 10 virtual users and
> unlimited number of requests. Within a minute or two Geronimo stopped
> responding to any request logging to console something like
> ...
> 18:32:56,180 WARN [ThreadedServer] EXCEPTION
> java.lang.OutOfMemoryError
> 18:32:57,211 WARN [ThreadedServer] EXCEPTION
> java.lang.OutOfMemoryError
> ...
>
> Has someone used any specific VM options to run Geronimo smoothly? (As for
> me I've tried starting Geronimo with Java 1.4.2 Hotspot(TM) VM with -server
> option enabled).
>
> Any advice or reference could be helpful. Thank you.
> --
> Best regards,
> Maxim Berkultsev, Intel Middleware Products Division
>