You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Salman Akram <sa...@northbaysolutions.net> on 2012/07/15 21:19:10 UTC
JRockit with SOLR3.4/3.5
We used JRockit with SOLR1.4 as default JVM had mem issues (not only it was consuming more mem but didn't restrict to the max mem allocated to tomcat - jrockit did restrict to max mem). However, JRockit gives an error while using it with SOLR3.4/3.5. Any ideas, why?
*** This Message Has Been Sent Using BlackBerry Internet Service from Mobilink ***
Re: JRockit with SOLR3.4/3.5
Posted by Snehal Chennuru <sn...@gmail.com>.
I am running into a similar issue with Lucene 3.6 which I believe is used in
Solr 3.4.
Following is the exception stack trace:
2012-09-08 18:08:56,341 WARN [STDERR] (Load thread:) Exception in thread
"Load thread" java.lang.OutOfMemoryError: classblock allocation, 2814576
loaded, 2816K footprint, in check_alloc
(src/jvm/model/classload/classalloc.c:215).
Attempting to allocate 4320M bytes
There is insufficient native memory for the Java
Runtime Environment to continue.
Possible reasons:
The system is out of physical RAM or swap space
In 32 bit mode, the process size limit was hit
Possible solutions:
Reduce memory load on the system
Increase physical memory or swap space
Check if swap backing store is full
Use 64 bit Java on a 64 bit OS
Decrease Java heap size (-Xmx/-Xms)
Decrease number of Java threads
Decrease Java thread stack sizes (-Xss)
Disable compressed references (-XXcompressedRefs=false)
2012-09-08 18:08:56,341 WARN [STDERR] (Load thread:)
2012-09-08 18:08:56,341 WARN [STDERR] (Load thread:) at
java.lang.ClassLoader.defineClass1(Native Method)
2012-09-08 18:08:56,341 WARN [STDERR] (Load thread:) at
java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
2012-09-08 18:08:56,341 WARN [STDERR] (Load thread:) at
java.lang.ClassLoader.defineClass(ClassLoader.java:615)
2012-09-08 18:08:56,341 WARN [STDERR] (Load thread:) at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
2012-09-08 18:08:56,341 WARN [STDERR] (Load thread:) at
java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
2012-09-08 18:08:56,341 WARN [STDERR] (Load thread:) at
java.net.URLClassLoader.access$000(URLClassLoader.java:58)
2012-09-08 18:08:56,341 WARN [STDERR] (Load thread:) at
java.net.URLClassLoader$1.run(URLClassLoader.java:197)
2012-09-08 18:08:56,341 WARN [STDERR] (Load thread:) at
java.net.URLClassLoader.findClass(URLClassLoader.java:190)
2012-09-08 18:08:56,341 WARN [STDERR] (Load thread:) at
java.lang.ClassLoader.loadClass(ClassLoader.java:306)
2012-09-08 18:08:56,341 WARN [STDERR] (Load thread:) at
sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
2012-09-08 18:08:56,341 WARN [STDERR] (Load thread:) at
java.lang.ClassLoader.loadClass(ClassLoader.java:247)
2012-09-08 18:08:56,341 WARN [STDERR] (Load thread:) at
org.apache.log4j.spi.ThrowableInformation.getThrowableStrRep(ThrowableInformation.java:87)
2012-09-08 18:08:56,341 WARN [STDERR] (Load thread:) at
org.apache.log4j.spi.LoggingEvent.getThrowableStrRep(LoggingEvent.java:413)
2012-09-08 18:08:56,341 WARN [STDERR] (Load thread:) at
org.apache.log4j.WriterAppender.subAppend(WriterAppender.java:313)
2012-09-08 18:08:56,341 WARN [STDERR] (Load thread:) at
org.apache.log4j.RollingFileAppender.subAppend(RollingFileAppender.java:276)
2012-09-08 18:08:56,341 WARN [STDERR] (Load thread:) at
org.apache.log4j.WriterAppender.append(WriterAppender.java:162)
2012-09-08 18:08:56,341 WARN [STDERR] (Load thread:) at
org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:251)
2012-09-08 18:08:56,341 WARN [STDERR] (Load thread:) at
org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:66)
2012-09-08 18:08:56,341 WARN [STDERR] (Load thread:) at
org.apache.log4j.Category.callAppenders(Category.java:206)
2012-09-08 18:08:56,341 WARN [STDERR] (Load thread:) at
org.apache.log4j.Category.forcedLog(Category.java:391)
2012-09-08 18:08:56,341 WARN [STDERR] (Load thread:) at
org.apache.log4j.Category.warn(Category.java:1060)
2012-09-08 18:08:56,341 WARN [STDERR] (Load thread:) at
com.teneo.esa.common.util.Logger.printStack(Logger.java:584)
JVM details:
Jrockit R28.2.3, Xms4320m, Xmx4320m.
The code under question is trying to fetch all the documents one at a time
from the index. Does this have any problems?
--
View this message in context: http://lucene.472066.n3.nabble.com/JRockit-with-SOLR3-4-3-5-tp3995148p4006389.html
Sent from the Solr - User mailing list archive at Nabble.com.
Re: JRockit with SOLR3.4/3.5
Posted by Salman Akram <sa...@northbaysolutions.net>.
Michael,
Thanks for the response. Below is the stack trace.
Note: Our environment is 64 bit and the Initial Pool size is set to 4GB and
Max pool size is 12GB so it doesn't makes sense why it tries to allocate
24GB (even that is available as the total RAM is 64GB).
This issue doesn't come with SOLR 1.4
-----------------------------------------
SEVERE: Error waiting for multi-thread deployment of directories to
completehostConfig.deployWar=Deploying web application archive {0}
java.util.concurrent.ExecutionException: java.lang.OutOfMemoryError:
classblock allocation, 1535880 loaded, 1536K footprint, in check_alloc
(src/jvm/model/classload/classalloc.c:215).
Attempting to allocate 24000M bytes
There is insufficient native memory for the Java
Runtime Environment to continue.
Possible reasons:
The system is out of physical RAM or swap space
In 32 bit mode, the process size limit was hit
Possible solutions:
Reduce memory load on the system
Increase physical memory or swap space
Check if swap backing store is full
Use 64 bit Java on a 64 bit OS
Decrease Java heap size (-Xmx/-Xms)
Decrease number of Java threads
Decrease Java thread stack sizes (-Xss)
Disable compressed references (-XXcompressedRefs=false)
at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222)
at java.util.concurrent.FutureTask.get(FutureTask.java:83)
at org.apache.catalina.startup.HostConfig.deployDirectories(
HostConfig.java:1018)
at org.apache.catalina.startup.HostConfig.deployApps(
HostConfig.java:475)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1412)
at org.apache.catalina.startup.HostConfig.lifecycleEvent(
HostConfig.java:312)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(
LifecycleSupport.java:119)
at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(
LifecycleBase.java:91)
at org.apache.catalina.util.LifecycleBase.setStateInternal(
LifecycleBase.java:401)
at org.apache.catalina.util.LifecycleBase.setState(
LifecycleBase.java:346)
at org.apache.catalina.core.ContainerBase.startInternal(
ContainerBase.java:1117)
at org.apache.catalina.core.StandardHost.startInternal(
StandardHost.java:782)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.core.ContainerBase$StartChild.call(
ContainerBase.java:1526)
at org.apache.catalina.core.ContainerBase$StartChild.call(
ContainerBase.java:1515)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:139)
at java.util.concurrent.ThreadPoolExecutor$Worker.
runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(
ThreadPoolExecutor.java:909)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.OutOfMemoryError: classblock allocation, 1535880
loaded, 1536K footprint, in check_alloc (src/jvm/model/classload/
classalloc.c:215).
Attempting to allocate 24000M bytes
There is insufficient native memory for the Java
Runtime Environment to continue.
Possible reasons:
The system is out of physical RAM or swap space
In 32 bit mode, the process size limit was hit
Possible solutions:
Reduce memory load on the system
Increase physical memory or swap space
Check if swap backing store is full
Use 64 bit Java on a 64 bit OS
Decrease Java heap size (-Xmx/-Xms)
Decrease number of Java threads
Decrease Java thread stack sizes (-Xss)
Disable compressed references (-XXcompressedRefs=false)
at sun.misc.Unsafe.defineClass(Native Method)
at sun.reflect.ClassDefiner.defineClass(ClassDefiner.java:45)
at sun.reflect.MethodAccessorGenerator$1.run(
MethodAccessorGenerator.java:381)
at sun.reflect.MethodAccessorGenerator.generate(
MethodAccessorGenerator.java:377)
at sun.reflect.MethodAccessorGenerator.generateConstructor(
MethodAccessorGenerator.java:76)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(
NativeConstructorAccessorImpl.java:30)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(
DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at java.lang.Class.newInstance0(Class.java:355)
at java.lang.Class.newInstance(Class.java:308)
at javax.xml.parsers.FactoryFinder.newInstance(FactoryFinder.java:147)
at javax.xml.parsers.FactoryFinder.find(FactoryFinder.java:233)
at javax.xml.parsers.SAXParserFactory.newInstance(
SAXParserFactory.java:128)
at org.apache.tomcat.util.digester.Digester.getFactory(
Digester.java:470)
at org.apache.tomcat.util.digester.Digester.getParser(Digester.java:677)
at org.apache.catalina.startup.ContextConfig.init(
ContextConfig.java:780)
at org.apache.catalina.startup.ContextConfig.lifecycleEvent(
ContextConfig.java:320)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(
LifecycleSupport.java:119)
at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(
LifecycleBase.java:90)
at org.apache.catalina.util.LifecycleBase.setStateInternal(
LifecycleBase.java:401)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:110)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:139)
at org.apache.catalina.core.ContainerBase.addChildInternal(
ContainerBase.java:866)
at org.apache.catalina.core.ContainerBase.addChild(
ContainerBase.java:842)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:615)
at org.apache.catalina.startup.HostConfig.deployDirectory(
HostConfig.java:1095)
at org.apache.catalina.startup.HostConfig$DeployDirectory.
run(HostConfig.java:1617)
at java.util.concurrent.Executors$RunnableAdapter.
call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.
runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(
ThreadPoolExecutor.java:908)
... 1 more
Jun 7, 2012 4:03:04 AM org.apache.coyote.AbstractProtocol start
On Mon, Jul 16, 2012 at 2:20 AM, Michael Della Bitta <
michael.della.bitta@appinions.com> wrote:
> Hello, Salman,
>
> It would probably be helpful if you included the text/stack trace of
> the error you're encountering, plus any other pertinent system
> information you can think of.
>
> One thing to remember is the memory usage you tune with Xmx is only
> the maximum size of the heap, and there are other types of memory
> usage by the JVM that don't fall under that (Permgen space, memory
> mapped files, etc).
>
> Michael Della Bitta
>
> ------------------------------------------------
> Appinions, Inc. -- Where Influence Isn’t a Game.
> http://www.appinions.com
>
>
> On Sun, Jul 15, 2012 at 3:19 PM, Salman Akram
> <sa...@northbaysolutions.net> wrote:
> > We used JRockit with SOLR1.4 as default JVM had mem issues (not only it
> was consuming more mem but didn't restrict to the max mem allocated to
> tomcat - jrockit did restrict to max mem). However, JRockit gives an error
> while using it with SOLR3.4/3.5. Any ideas, why?
> >
> > *** This Message Has Been Sent Using BlackBerry Internet Service from
> Mobilink ***
>
--
Regards,
Salman Akram
Project Manager - Intelligize
NorthBay Solutions
410-G4 Johar Town, Lahore
Off: +92-42-35290152
Cell: +92-302-8495621
Re: JRockit with SOLR3.4/3.5
Posted by Michael Della Bitta <mi...@appinions.com>.
Hello, Salman,
It would probably be helpful if you included the text/stack trace of
the error you're encountering, plus any other pertinent system
information you can think of.
One thing to remember is the memory usage you tune with Xmx is only
the maximum size of the heap, and there are other types of memory
usage by the JVM that don't fall under that (Permgen space, memory
mapped files, etc).
Michael Della Bitta
------------------------------------------------
Appinions, Inc. -- Where Influence Isn’t a Game.
http://www.appinions.com
On Sun, Jul 15, 2012 at 3:19 PM, Salman Akram
<sa...@northbaysolutions.net> wrote:
> We used JRockit with SOLR1.4 as default JVM had mem issues (not only it was consuming more mem but didn't restrict to the max mem allocated to tomcat - jrockit did restrict to max mem). However, JRockit gives an error while using it with SOLR3.4/3.5. Any ideas, why?
>
> *** This Message Has Been Sent Using BlackBerry Internet Service from Mobilink ***