Hello,
I recently started attempting to use elasticsearch to store some data.
In the learning process, I was doing ok until I attempted using the bulk
api.
I used the something along the lines of:
conn = ES(url, timeout, bulksize)
for each (tuple)
data = something(tuple)
conn.index
nodes are, what your dataset size
> is, what java version you are on?
>
> On 9 December 2014 at 15:48, Hui >
> wrote:
>
>> Hi,
>>
>> My elasticsearch cluster recently has a high response time.
>>
>> Elasticsearch cluster (version 1.1.1 + num
Hi,
My elasticsearch cluster recently has a high response time.
Elasticsearch cluster (version 1.1.1 + number of node : 8)
Java client (client.transport.sniff is true)
After checking, I found that all java clients have the exception
org.elasticsearch.transport.ReceiveTimeoutTransportException...
Hi All,
My elasticsearch version is 1.1.1. I have a 20 shards and 0 replica index
having 4m docs.
It is fast (1ms) for my query.
{
- took: 1
- timed_out: false
- _shards: {
- total: 20
- successful: 20
- failed: 0
}
- hits: {
- total: 0
- max_sco
using cached for both index and search thread pool?
curl -XPUT localhost:9200/_cluster/settings -d '{
"persistent" : {
"threadpool.index.type" : "cached",
"threadpool.search.type" : "cached"
}
}'
On Monday, April 28, 2014 5:40:14 PM UTC+8, Le Thanh Nguyen wrote:
>
> Hi,
>
Hi All,
In elasticsearch 0.90.1, we do the following :
curl -XPUT 'http://localhost:9200/testing/' -d '{
"settings" : {
"index" : {
"number_of_shards" : 1,
"number_of_replicas" : 0,
"refresh_interval" : "1m"
}
}
}'
curl -XPUT 'http://l
Sorry All.
I've verified that the slow problem is related to the
reason failed to ping, tried [3] times, each with maximum [30s] timeout
Thanks.
On Friday, March 14, 2014 12:02:36 PM UTC+8, Hui wrote:
>
> Hi All,
>
> After testing in another cluster, I found that t
Hi All,
After testing in another cluster, I found that the cluster can be connected
but it was very slow.
At this moment, every normal request(~50ms) becomes 41732ms to 85984ms
while the cluster is in Yellow health and there is no unassigned shard(s).
It becomes 50ms again after the problem no
le to verify if its merely a warning for
> you? if so, i might just not worry about this for now.
>
> On Thursday, March 13, 2014 5:15:36 AM UTC-4, Hui wrote:
>>
>> Hi Dome,
>>
>> Do you mean the service of 10.1.4.196 is not open? Yes, the service
>>
understand it wrongly?
Thanks
On Thursday, March 13, 2014 4:48:17 PM UTC+8, Dome.C.Wei wrote:
>
> That must be the service not open.
>
> 在 2014年3月13日星期四UTC+8下午2时10分22秒,Hui写道:
>>
>> Hi Mark,
>>
>> Thanks for replying.
>>
>> The master (10.1.4.197) and other
gt; Mark Walkom
>
> Infrastructure Engineer
> Campaign Monitor
> email: ma...@campaignmonitor.com
> web: www.campaignmonitor.com
>
>
> On 13 March 2014 16:54, Hui > wrote:
>
>> Hi All,
>>
>>
>> This is the log for the case.
>>
>>
>
Hi All,
This is the log for the case.
The node 10.1.4.196 is removed at 14:08 due to machine reboot, the client keeps
trying to connect to the elasticsearch cluster but fails.
Master Node :
[2014-03-08 14:08:26,531][INFO ][cluster.service ] [10.1.4.197:9202]
removed {[10.1.4.196:920
Hi
we are running on Linux (ubuntu).
The ZFS is set to standard (default).
On Wednesday, January 1, 2014 12:43:35 AM UTC+8, Jörg Prante wrote:
>
> Do you run ZFS in sync mode? Are you on Solaris?
>
> Jörg
>
>
--
You received this message because you are subscribed to the Google Groups
"e
Dear All
Could I check whether anyone deploy ElasticSearch on ZFS?
We are facing some problems with our ES instance on ZFS. When indexing (and
idle mode) there seems to be high volume of reads on the drives using ZFS,
thus resulting in high iowait, low CPU utilization. However, there is very
14 matches
Mail list logo