I used Elasticsearch-1.1.0 to index tweets. The indexing process is okay. Then I upgraded the version. Now I use Elasticsearch-1.3.2, and I get this message randomly:
<You also should check if all fine with elastic. Some shard can be unavailable, here is nice doc about possible reasons of unavailable shard https://www.datadoghq.com/blog/elasticsearch-unassigned-shards/
Increasing various timeout options may immediately resolve issues, but does not address the root cause.
Provided the ElasticSearch service is available and the indexes are healthy, try increasing the the Java minimum and maximum heap sizes: see https://www.elastic.co/guide/en/elasticsearch/reference/current/jvm-options.html .
TL;DR Edit /etc/elasticsearch/jvm.options -Xms1g
and -Xmx1g
Just in case someone else has tried everything here and nothing has worked...
Slipt the problem in two, check if the Elasticsearch it is really ok, try running any of the commands below on the command line:
curl localhost:9200/_cat/indices
curl -XGET 'http://localhost:9200/_cluster/state?pretty'
In case they didn't work (so, nothing to do with Python), check the /etc/elasticsearch.yaml (config at Ubuntu, packaged, in this case). probably the file is badly configured (I had it because of old experiments). Try to comment out everything and check the commands again, then if it worked, so come back to Python.
Try this:
es = Elasticsearch(timeout=30, max_retries=10, retry_on_timeout=True)
It might won't fully avoid ReadTimeoutError
, but it minimalize them.
For what it's worth, I found that this seems to be related to a broken index state.
It's very difficult to reliably recreate this issue, but I've seen it several times; operations run as normal except certain ones which periodically seem to hang ES (specifically refreshing an index it seems).
Deleting an index (curl -XDELETE http://localhost:9200/foo
) and reindexing from scratch fixed this for me.
I recommend periodically clearing and reindexing if you see this behaviour.
Its hard to give a direct answer since the error your seeing might be associated with the client you are using. However a solution might be one of the following:
1.Increase the default timeout Globally when you create the ES client by passing the timeout parameter. Example in Python
es = Elasticsearch(timeout=30)
2.Set the timeout per request made by the client. Taken from Elasticsearch Python docs below.
# only wait for 1 second, regardless of the client's default
es.cluster.health(wait_for_status='yellow', request_timeout=1)
The above will give the cluster some extra time to respond