geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rajiv M" <rmadasser...@gmail.com>
Subject Re: VM options to run Geronimo
Date Thu, 30 Mar 2006 07:12:13 GMT
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 <caustin@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
> > <mailto:rmadassery77@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
> >     <mailto:jgenender@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.~~~

Mime
View raw message