Weird problem with routing performance
Hi all,
i have a weird (at least in my oppinion) situation on my environment.
my hardware:
3 data nodes with 32GB of ram (16GB of Java heap for ES)
using data from logstash, stored per day manner
with 360 5*shard + 1 replica indexes -* NO ROUTING *-> grouped by alias
named* norouting*
and same indexes (different names of course) reindexed with new mapping:
and 360 4*shard + 1 replica indexes - *WITH ROUTING * -> grouped by alias
named* routing*
about *2 billions *of docs,
about* 0.8 TB* of data
I have 4 customers that I want to split to their own indices by routing to
increase performance when querying the whole year of data.
3 customers are similar size, and one is about 2x times larger than others.
When I performed tests (I cleared the cache with _cache/clear before each
query)
Simple query that I was using for indexes with routing:
-
/*routing*/_search?routing=CUSTOMER1
{
"query": {
"filtered": {
"query": {
"match_all": {}
},
"filter": {
"term": {
"Customer.raw": "CUSTOMER1"
}
}
}
}
}
result: *360 indices read, 18 sec response*
-
and the indexes without routing
/*norouting*/_search
{
"query": {
"filtered": {
"query": {
"match_all": {}
},
"filter": {
"term": {
"Customer.raw": "CUSTOMER1"
}
}
}
}
}
result: *1800 indices read, 7 sec response*
*... no matter which customer I want to find, results are similar,
searching with routing is always almoust 2.5 times slower !*
This does not make any sense ... should be opposite in my oppinion.
Any help would be much appreciated !. After I've read about routing I was
happy and hoping I could speed up the queries without adding additional
hardware ... now I'm very sceptical.
--
You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to elasticsearch+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/eb1ab06d-f738-4b5e-a333-710f3b26b30a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Corrupted ElasticSearch index ?
Hi, we tried both ways but: First worked but was temporary and worked as index quickfix (after powerdown it was lost again), of course we used the rest interfaces to fix mappings that were already broken (we could not pump all data again so we had to fix it somehow). We applied the mapping file as default (for all indexes) to avoid the problem in future, we knew that all indexes can be started with same mapping. 17-03-2014 17:56, "Mac Jouz" napisał(a): > Hi, > > Thanks Karol, changing ES version does not change the problem indeed. > > 2 complementary questions if I may: > - You wrote that you copied the mapping file on ES location, did you try a > way to do so dynamically with a REST call ? > - Otherwise did you apply the modification for the specific "corrupted" > index or copy the mapping file in default config ES location (that is to > say that it was valid for all index ?) > > Regards > > José > > > > Le dimanche 16 mars 2014 16:37:19 UTC+1, bizzorama a écrit : >> >> Hi, >> >> it turned out that it was not a problem of ES version (we tested on both >> 0.90.10 and 0.90.9) but just a ES bug ... >> after restarting pc or even just the service indices got broken ... we >> found out that this was the case of missing mappings. >> We observed that broken indices had their mappings corrupted (only some >> default fields were observed). >> You can check this by calling: http:\\es_address:9200\indexName\_mapping >> >> Our mappings were dynamic (not set manually - just figured out by ES when >> the records were incoming). >> >> The solution was to add a static mapping file like the one described here: >> http://www.elasticsearch.org/guide/en/elasticsearch/ >> reference/current/mapping-conf-mappings.html (we added the default one). >> >> I just copied mappings from a healty index, made some changes, turned it >> to a mapping file and copied to the ES server. >> >> Now everything works just fine. >> >> Regards, >> Karol >> >> >> W dniu niedziela, 16 marca 2014 14:54:00 UTC+1 użytkownik Mac Jouz >> napisał: >>> >>> >>> Hi Bizzorama, >>> >>> I had a similar problem with the same configuration than you gave. >>> ES ran since the 11th of February and was fed every day at 6:00 AM by 2 >>> LS. >>> Everything worked well (kibana reports were correct and no data loss) >>> until >>> I restarted yesterday ES :-( >>> Among 30 index (1 per day), 4 were unusable and data within kibana report >>> for the related period were unavailable (same org.elasticsearch.search. >>> facet.FacetPhaseExecutionException: Facet[0]: (key) field [@timestamp] >>> not found) >>> >>> Do you confirm when you downgraded ES to 0.90.9 that you retrieved your >>> data >>> (i.e you was able to show your data in kibana reports) ? >>> >>> I will try to downgrade ES version as you suggested and will let you know >>> more >>> >>> Thanks for your answer >>> >>> >>> >>> Sorry for the delay. >>> >>> Looks like you were right, after downgrading ES to 0.90.9 i couldn't >>> reproduce the issue in such manner. >>> >>> Unfortunately, I found some other problems, and one looks like a blocker >>> >>> >>> After whole ES cluster powerdown, ES just started replaying 'no mapping >>> for ... ' for each request. >>> >>> W dniu czwartek, 20 lutego 2014 16:42:20 UTC+1 użytkownik Binh Ly >>> napisał: >>>> >>>> Your error logs seem to indicate some kind of version mismatch. Is it >>>> possible for you to test LS 1.3.2 against ES 0.90.9 and take a sample of >>>> raw logs from those 3 days and test them through to see if those 3 days >>>> work in Kibana? The reason I ask is because LS 1.3.2 (specifically the >>>> elasticsearch output) was built using the binaries from ES 0.90.9. >>>> >>>> Thanks. >>>> >>> >>> Le mardi 11 février 2014 13:18:01 UTC+1, bizzorama a écrit : >>>> >>>> Hi, >>>> >>>> I've noticed a very disturbing ElasticSearch behaviour ... >>>> my environment is: >>>> >>>> 1 logstash (1.3.2) (+ redis to store some data) + 1 elasticsearch >>>> (0.90.10) + kibana >>>> >>>> which process about 7 000 000 records per day, >>>> everything worked fine on our test environment, untill we run some >>>
Re: Corrupted ElasticSearch index ?
No, when things are running everything is ok, indexes break during restart/powerdown 17-03-2014 13:11, "Clinton Gormley" napisał(a): > Are you sure you didn't run out of disk space or file handles at some > stage, or have an OOM exception? > > > On 16 March 2014 16:37, bizzorama wrote: > >> Hi, >> >> it turned out that it was not a problem of ES version (we tested on both >> 0.90.10 and 0.90.9) but just a ES bug ... >> after restarting pc or even just the service indices got broken ... we >> found out that this was the case of missing mappings. >> We observed that broken indices had their mappings corrupted (only some >> default fields were observed). >> You can check this by calling: http:\\es_address:9200\indexName\_mapping >> >> Our mappings were dynamic (not set manually - just figured out by ES when >> the records were incoming). >> >> The solution was to add a static mapping file like the one described here: >> >> http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/mapping-conf-mappings.html(we >> added the default one). >> >> I just copied mappings from a healty index, made some changes, turned it >> to a mapping file and copied to the ES server. >> >> Now everything works just fine. >> >> Regards, >> Karol >> >> >> W dniu niedziela, 16 marca 2014 14:54:00 UTC+1 użytkownik Mac Jouz >> napisał: >> >>> >>> Hi Bizzorama, >>> >>> I had a similar problem with the same configuration than you gave. >>> ES ran since the 11th of February and was fed every day at 6:00 AM by 2 >>> LS. >>> Everything worked well (kibana reports were correct and no data loss) >>> until >>> I restarted yesterday ES :-( >>> Among 30 index (1 per day), 4 were unusable and data within kibana report >>> for the related period were unavailable (same org.elasticsearch.search. >>> facet.FacetPhaseExecutionException: Facet[0]: (key) field [@timestamp] >>> not found) >>> >>> Do you confirm when you downgraded ES to 0.90.9 that you retrieved your >>> data >>> (i.e you was able to show your data in kibana reports) ? >>> >>> I will try to downgrade ES version as you suggested and will let you know >>> more >>> >>> Thanks for your answer >>> >>> >>> >>> Sorry for the delay. >>> >>> Looks like you were right, after downgrading ES to 0.90.9 i couldn't >>> reproduce the issue in such manner. >>> >>> Unfortunately, I found some other problems, and one looks like a blocker >>> >>> >>> After whole ES cluster powerdown, ES just started replaying 'no mapping >>> for ... ' for each request. >>> >>> W dniu czwartek, 20 lutego 2014 16:42:20 UTC+1 użytkownik Binh Ly >>> napisał: >>>> >>>> Your error logs seem to indicate some kind of version mismatch. Is it >>>> possible for you to test LS 1.3.2 against ES 0.90.9 and take a sample of >>>> raw logs from those 3 days and test them through to see if those 3 days >>>> work in Kibana? The reason I ask is because LS 1.3.2 (specifically the >>>> elasticsearch output) was built using the binaries from ES 0.90.9. >>>> >>>> Thanks. >>>> >>> >>> Le mardi 11 février 2014 13:18:01 UTC+1, bizzorama a écrit : >>>> >>>> Hi, >>>> >>>> I've noticed a very disturbing ElasticSearch behaviour ... >>>> my environment is: >>>> >>>> 1 logstash (1.3.2) (+ redis to store some data) + 1 elasticsearch >>>> (0.90.10) + kibana >>>> >>>> which process about 7 000 000 records per day, >>>> everything worked fine on our test environment, untill we run some >>>> tests for a longer period (about 15 days). >>>> >>>> After that time, kibana was unable to show any data. >>>> I did some investigation and it looks like some of the indexes (for 3 >>>> days to be exact) seem to be corrupted. >>>> Now every query from kibana, using those corrupted indexes - failes. >>>> >>>> Errors read from elasticsearch logs: >>>> >>>> - org.elasticsearch.search.facet.FacetPhaseExecutionException: >>>> Facet[terms]: failed to find mapping for Name* ... a couple of other >>>> columns* >>>> - org.elasticsearch.search.facet.FacetPhaseExecutionException: Facet >&
Re: Corrupted ElasticSearch index ?
Hi, it turned out that it was not a problem of ES version (we tested on both 0.90.10 and 0.90.9) but just a ES bug ... after restarting pc or even just the service indices got broken ... we found out that this was the case of missing mappings. We observed that broken indices had their mappings corrupted (only some default fields were observed). You can check this by calling: http:\\es_address:9200\indexName\_mapping Our mappings were dynamic (not set manually - just figured out by ES when the records were incoming). The solution was to add a static mapping file like the one described here: http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/mapping-conf-mappings.html (we added the default one). I just copied mappings from a healty index, made some changes, turned it to a mapping file and copied to the ES server. Now everything works just fine. Regards, Karol W dniu niedziela, 16 marca 2014 14:54:00 UTC+1 użytkownik Mac Jouz napisał: > > > Hi Bizzorama, > > I had a similar problem with the same configuration than you gave. > ES ran since the 11th of February and was fed every day at 6:00 AM by 2 LS. > Everything worked well (kibana reports were correct and no data loss) until > I restarted yesterday ES :-( > Among 30 index (1 per day), 4 were unusable and data within kibana report > for the related period were unavailable (same > org.elasticsearch.search.facet.FacetPhaseExecutionException: Facet[0]: > (key) field [@timestamp] not found) > > Do you confirm when you downgraded ES to 0.90.9 that you retrieved your > data > (i.e you was able to show your data in kibana reports) ? > > I will try to downgrade ES version as you suggested and will let you know > more > > Thanks for your answer > > > > Sorry for the delay. > > Looks like you were right, after downgrading ES to 0.90.9 i couldn't > reproduce the issue in such manner. > > Unfortunately, I found some other problems, and one looks like a blocker > > > After whole ES cluster powerdown, ES just started replaying 'no mapping > for ... ' for each request. > > W dniu czwartek, 20 lutego 2014 16:42:20 UTC+1 użytkownik Binh Ly napisał: >> >> Your error logs seem to indicate some kind of version mismatch. Is it >> possible for you to test LS 1.3.2 against ES 0.90.9 and take a sample of >> raw logs from those 3 days and test them through to see if those 3 days >> work in Kibana? The reason I ask is because LS 1.3.2 (specifically the >> elasticsearch output) was built using the binaries from ES 0.90.9. >> >> Thanks. >> > > Le mardi 11 février 2014 13:18:01 UTC+1, bizzorama a écrit : >> >> Hi, >> >> I've noticed a very disturbing ElasticSearch behaviour ... >> my environment is: >> >> 1 logstash (1.3.2) (+ redis to store some data) + 1 elasticsearch >> (0.90.10) + kibana >> >> which process about 7 000 000 records per day, >> everything worked fine on our test environment, untill we run some tests >> for a longer period (about 15 days). >> >> After that time, kibana was unable to show any data. >> I did some investigation and it looks like some of the indexes (for 3 >> days to be exact) seem to be corrupted. >> Now every query from kibana, using those corrupted indexes - failes. >> >> Errors read from elasticsearch logs: >> >> - org.elasticsearch.search.facet.FacetPhaseExecutionException: >> Facet[terms]: failed to find mapping for Name* ... a couple of other >> columns* >> - org.elasticsearch.search.facet.FacetPhaseExecutionException: Facet [0]: >> (key) field [@timestamp] not found >> >> ... generaly all queries end with those errors >> >> When elasticsearch is started we find something like this: >> >> [2014-02-07 15:02:08,147][WARN ][transport.netty ] [Name] >> Message not fully read (request) for [243445] and action >> [cluster/nodeIndexCreated], resetting >> [2014-02-07 15:02:08,147][WARN ][transport.netty ] [Name] >> Message not fully read (request) for [249943] and action >> [cluster/nodeIndexCreated], resetting >> [2014-02-07 15:02:08,147][WARN ][transport.netty ] [Name] >> Message not fully read (request) for [246740] and action >> [cluster/nodeIndexCreated], resetting >> >> And a little observations: >> >> 1. When using elasticsearch-head plugin, when querying records >> 'manually', i can see only elasticsearch columns (_index, _type, _id, >> _score). >> But when I 'randomly' select columns and overview their raw json they >> look ok. >> >> 2, When I tried
Re: Corrupted ElasticSearch index ?
Sorry for the delay. Looks like you were right, after downgrading ES to 0.90.9 i couldn't reproduce the issue in such manner. Unfortunately, I found some other problems, and one looks like a blocker After whole ES cluster powerdown, ES just started replaying 'no mapping for ... ' for each request. W dniu czwartek, 20 lutego 2014 16:42:20 UTC+1 użytkownik Binh Ly napisał: > > Your error logs seem to indicate some kind of version mismatch. Is it > possible for you to test LS 1.3.2 against ES 0.90.9 and take a sample of > raw logs from those 3 days and test them through to see if those 3 days > work in Kibana? The reason I ask is because LS 1.3.2 (specifically the > elasticsearch output) was built using the binaries from ES 0.90.9. > > Thanks. > -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/c04a560e-58b3-4ced-bcf1-97d62e8e3703%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Corrupted ElasticSearch index ?
> Really, no clue? > -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/b864ece4-a47c-4999-8d9d-45ab1e11403b%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Corrupted ElasticSearch index ?
Hi, I've noticed a very disturbing ElasticSearch behaviour ... my environment is: 1 logstash (1.3.2) (+ redis to store some data) + 1 elasticsearch (0.90.10) + kibana which process about 7 000 000 records per day, everything worked fine on our test environment, untill we run some tests for a longer period (about 15 days). After that time, kibana was unable to show any data. I did some investigation and it looks like some of the indexes (for 3 days to be exact) seem to be corrupted. Now every query from kibana, using those corrupted indexes - failes. Errors read from elasticsearch logs: - org.elasticsearch.search.facet.FacetPhaseExecutionException: Facet[terms]: failed to find mapping for Name* ... a couple of other columns* - org.elasticsearch.search.facet.FacetPhaseExecutionException: Facet [0]: (key) field [@timestamp] not found ... generaly all queries end with those errors When elasticsearch is started we find something like this: [2014-02-07 15:02:08,147][WARN ][transport.netty ] [Name] Message not fully read (request) for [243445] and action [cluster/nodeIndexCreated], resetting [2014-02-07 15:02:08,147][WARN ][transport.netty ] [Name] Message not fully read (request) for [249943] and action [cluster/nodeIndexCreated], resetting [2014-02-07 15:02:08,147][WARN ][transport.netty ] [Name] Message not fully read (request) for [246740] and action [cluster/nodeIndexCreated], resetting And a little observations: 1. When using elasticsearch-head plugin, when querying records 'manually', i can see only elasticsearch columns (_index, _type, _id, _score). But when I 'randomly' select columns and overview their raw json they look ok. 2, When I tried to process same data again - everything is ok Is it possible that some corrupted data found its way to elasticsearch and now whole index is broken ? Can this be fixed ? reindexed or sth ? This data is very importand and can't be lost ... Best Regards, Karol -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/426a8411-bf03-42d3-9b77-1e45dace98ff%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
