It seems to work now.
We simply added
/ulimit -v unlimited /
to our tomcat-startup-script.
@Yonik: Thanks again!
Best regards,
Sebastian
--
View this message in context:
http://lucene.472066.n3.nabble.com/Solr-3-3-Exception-in-thread-Lucene-Merge-Thread-1-tp3185248p3200105.html
mdz-munich wrote:
Yeah, indeed.
But since the VM is equipped with plenty of RAM (22GB) and it works so far
(Solr 3.2) very well with this setup, I AM slightly confused, am I?
Maybe we should LOWER the dedicated Physical Memory? The remaining 10GB
are used for a second tomcat (8GB) and
I was wrong.
After rebooting tomcat we discovered a new sweetness:
/SEVERE: REFCOUNT ERROR: unreferenced org.apache.solr.core.SolrCore@3c753c75
(core.name) has a reference count of 1
22.07.2011 11:52:07 org.apache.solr.common.SolrException log
SEVERE: java.lang.RuntimeException:
IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux amd64-64
I'm confused why MMapDirectory is getting used with the IBM JVM... I
had thought it would default to NIOFSDirectory on Linux w/ a non
Oracle JVM.
Are you specifically selecting MMapDirectory in solrconfig.xml?
Can you try the Oracle JVM
On Fri, Jul 22, 2011 at 9:44 AM, Yonik Seeley
yo...@lucidimagination.com wrote:
IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux amd64-64
I'm confused why MMapDirectory is getting used with the IBM JVM... I
had thought it would default to NIOFSDirectory on Linux w/ a non
Oracle JVM.
I
Hi Yonik,
thanks for your reply!
Are you specifically selecting MMapDirectory in solrconfig.xml?
Nope.
We installed Oracle's Runtime from
http://java.com/de/download/linux_manual.jsp?locale=de
/java.runtime.name = Java(TM) SE Runtime Environment
sun.boot.library.path =
OK, best guess is that you're going over some per-process address space limit.
Try seeing what ulimit -a says.
-Yonik
http://www.lucidimagination.com
On Fri, Jul 22, 2011 at 12:51 PM, mdz-munich
sebastian.lu...@bsb-muenchen.de wrote:
Hi Yonik,
thanks for your reply!
Are you specifically
It says:
/core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 257869
max locked memory (kbytes, -l) 64
max memory size
Yep, there ya go... your OS configuration is limiting you to 27G of
virtual address space per process. Consider setting that to
unlimited.
-Yonik
http://www.lucidimagination.com
On Fri, Jul 22, 2011 at 1:05 PM, mdz-munich
sebastian.lu...@bsb-muenchen.de wrote:
It says:
/core file size
Maybe it's important:
- The OS (Open Suse 10) is virtualized on VMWare
- Network Attached Storage
Best regards
Sebastian
--
View this message in context:
http://lucene.472066.n3.nabble.com/Solr-3-3-Exception-in-thread-Lucene-Merge-Thread-1-tp3185248p3191986.html
Sent from the Solr - User
Update.
After adding 1626 documents without doing a commit or optimize:
/Exception in thread Lucene Merge Thread #1
org.apache.lucene.index.MergePolicy$MergeException: java.io.IOException: Map
failed
at
Here we go ...
This time we tried to use the old LogByteSizeMergePolicy and
SerialMergeScheduler:
mergePolicy class=org.apache.lucene.index.LogByteSizeMergePolicy/
mergeScheduler class=org.apache.lucene.index.SerialMergeScheduler/
We did this before, just to be sure ...
~300 Documents:
/
Says it is caused by a Java out of memory error, no?
-Original Message-
From: mdz-munich [mailto:sebastian.lu...@bsb-muenchen.de]
Sent: Wednesday, July 20, 2011 9:18 AM
To: solr-user@lucene.apache.org
Subject: Re: Solr 3.3: Exception in thread Lucene Merge Thread #1
Here we go
Yeah, indeed.
But since the VM is equipped with plenty of RAM (22GB) and it works so far
(Solr 3.2) very well with this setup, I AM slightly confused, am I?
Maybe we should LOWER the dedicated Physical Memory? The remaining 10GB are
used for a second tomcat (8GB) and the OS (Suse). As far as I
14 matches
Mail list logo
