On 2/25/2013 11:05 AM, zqzuk wrote:
I have deliberately allocated 32G to JVM, with the command "java -Xmx32000m
-jar start.jar" etc. I am using our server which I think has a total of 48G.
However it still crashes because of that error when I specify any keywords
in my query. The only query that worked, as I said, is "q=*:*"
I also realised that the best configuration would be a cloudsetting. It's a
shame that I cannot split this index for that purpose but rather have to
re-index everything.
Yes, you would have to reindex in order to use SolrCloud with multiple
shards. There is an API available somewhere that can split Solr
indexes, which you might be able to use to create the shards using your
current index, but I don't know how well it works or where to find it.
But I very much would like to know exactly what has happened with that
error:
"java.lang.OutOfMemoryError: OutOfMemoryError likely caused by the Sun VM
Bug described in https://issues.apache.org/jira/browse/LUCENE-1566;
try calling FSDirectory.setReadChunkSize with a value smaller than the
current chunk size (2147483647)"
Especially what does the last line tell me?
The error message indicates that the problem MIGHT a bug in the
Sun/Oracle JVM. There is a workaround that's possible at the Lucene
level - setting the chunk size for the directory implementation. If you
were using Lucene directly, this would make perfect sense to you,
because you would already be writing java code. Because you're using
Solr, those details are hidden from you.
This is *only* a problem if your Java VM is 32-bit. If it's 64-bit,
this bug does not happen. If you are using a 32-bit Java, then you'll
want to make sure you're on a 64-bit OS and upgrade to a 64-bit java.
The output of "java -version" will explicitly say 64-Bit if that's what
it is:
[root@idxa2 idxbuild]# java -version
java version "1.6.0_38"
Java(TM) SE Runtime Environment (build 1.6.0_38-b05)
Java HotSpot(TM) 64-Bit Server VM (build 20.13-b02, mixed mode)
I would not attempt to run with an index this big on a 32-bit JVM.
Thanks,
Shawn
