Thanks Shawn,
I'm definitely not looking to just upping the timeout, like you say,
there's a bigger issue to be resolved.
My indexes are between 1m and up to 60m docs (30m per shard, ~70GB on
disk each).
All of these collections get completely refreshed at least once a day,
data may not actually be changing, but the JSON files are re-uploaded
currently.
I've used a 3GB heap for all of the nodes, perhaps that needs upping a bit.
Strange that I've not seen this issue before though.
Any good advice/guidance for analysing and tweaking GC?
On 29/04/16 18:52, Shawn Heisey wrote:
On 4/28/2016 3:13 PM, Robert Brown wrote:
I operate several collections (about 7-8) all using the same 5-node
ZooKeeper cluster. They've been in production for 3 months, with only
2 previous issues where a Solr node went down.
Tonight, during several updates to the various collections, a handful
failed due to the below error.
Could this be related to ZooKeeper in any way? If so, what could I
check to ensure everything is running smoothly?
The collections are a mix of 1 and 2 shards, all with 1 replica.
Updates are performed in batches of 1000 in JSON files.
Are there any other things I could/should be checking?
$VAR1 = {
'error' => {
'code' => 500,
'msg' => 'java.util.concurrent.TimeoutException:
Idle timeout expired: 50000/50000 ms',
This idle timeout is configured in Jetty. The default setting in the
jetty config provided with Solr 5.x is 50 seconds.
If your update requests are taking too long for the Jetty idle timeout,
then I think you're having a general performance problem with Solr.
Increasing the timeout might help in the short term, but unless you fix
the underlying performance issue, you'd probably just run into the new
timeout at some point in the future.
Most severe performance problems like this are memory related, and are
solved by adding more memory. Sometimes that is Java heap memory,
sometimes that is memory that is not allocated to a program. Sometimes
both are required.
Thanks,
Shawn
