Can you please not attach such large images to the list, it's easier for everyone if you can host and then link to them elsewhere instead :)
On 19 November 2014 18:48, Pavel P <[email protected]> wrote: > Thanks Jakub, it's interesting. > > For now I've solved the issue with the increasing the number of RELOCATING > shards: > [image: Inline image 1] > > Looks like it helps. > > Regards, > > On Wed, Nov 19, 2014 at 9:24 AM, Jakub Podeszwik <[email protected] > > wrote: > >> I've seen similar behaviour when i've had checksum some errors.There may >> be some info in your logs about it. In that case shard fail to be assigned >> because elasticsearch couldn't verify checksum of one or more of its >> segments. >> >> On Tuesday, 18 November 2014 14:17:02 UTC+1, Pavel P wrote: >> >>> It looks, that I have 2 shards unassigned, because two other shards were >>> stuck in "RELOCATING" state. >>> >>> >>> <https://lh5.googleusercontent.com/-TD84Uz8lg5Q/VGtGVXVIFVI/AAAAAAAAAK4/ITudefzX1qQ/s1600/ES_RELOCATING.png> >>> >>> And I think I have them migrating here and there, and while they are >>> trying to find the new home for themselves, it's not possible to allocate >>> those 2 shards. >>> I've tried to close the index and then open - when the index was closed >>> - all the remaining shards were allocated successfully, after I've opened >>> it again - no shards remain unassigned. >>> >>> So the current question is - why some shards are relocating constantly. >>> >>> >>> Regards, >>> >>> >>> >>> >>> On Monday, November 17, 2014 11:02:43 AM UTC+2, Pavel P wrote: >>>> >>>> Hi, >>>> >>>> I have a cluster from 5 nodes, where I store the information from the >>>> logstash. >>>> Recently I've tried to increase the number of shards in the logstash >>>> index to 20 (from 5). >>>> >>>> From the beginning everything went well, all the shards were allocated >>>> and the cluster state was green. >>>> >>>> But, currently, when the new index is started (at the beginning of the >>>> day), I met the situation when some shards are not allocated: >>>> >>>> >>>> <https://lh3.googleusercontent.com/-R3bWkXbXCbU/VGmwngnPOzI/AAAAAAAAAKY/9n8XlVCGPyc/s1600/Screen%2BShot%2B2014-11-17%2Bat%2B10.23.04%2BAM.png> >>>> >>>> Nothing happens during the day, while I thing the cluster has >>>> resources. >>>> >>>> If I would restart some nodes from the cluster, it could turn out that >>>> all the shards would be allocated. >>>> >>>> The idea which I'm trying to reach - more shards => each shard is >>>> smaller => it would allocate them faster, it would index faster, because of >>>> the indexing on each shard. >>>> >>>> Questions: >>>> >>>> 1. Why it is not able to allocate those shards during the index >>>> creation? >>>> 2. Why it does not allocate those shards during the day? >>>> 3. What is the recommended shards number for N nodes? >>>> >>>> Any thoughts are welcome. >>>> >>>> Regards, >>>> >>> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "elasticsearch" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/elasticsearch/q5Xkn9pc9EM/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/elasticsearch/c9ccce72-37ac-44d5-a016-ea8ef9a20e73%40googlegroups.com >> <https://groups.google.com/d/msgid/elasticsearch/c9ccce72-37ac-44d5-a016-ea8ef9a20e73%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > > *Pavel Polyakov* > > Software Engineer - PHP > > E-mail: [email protected] > Skype: pavel.polyakov.x1 > > <https://www.facebook.com/kreditech> > Kreditech Holding SSL GmbH > Am Sandtorkai 50, 20457 Hamburg, Germany > Office phone: +49 (0)40 - 605905-60 > Authorized representatives: Sebastian Diemer, Alexander Graubner-Müller > Company registration: Hamburg HRB122027 > > www.kreditech.com > facebook.com/kreditech <https://www.facebook.com/kreditech> > > <https://www.facebook.com/kreditech> > > This e-mail contains confidential and/or legally protected information. If > you are not the intended recipient or if you have received this e-mail by > error please notify the sender immediately and destroy this e-mail. Any > unauthorized review, copying, disclosure or distribution of the material in > this e-mail is strictly forbidden. The contents of this e-mail is legally > binding only if it is confirmed by letter or fax. The sending of e-mails to > us does not have any period-protecting effect. Thank you for your > cooperation. > > -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elasticsearch/CAFVUaqO9zccHa-EO0e_75_B9ZNDuF_RVCBkn9OLs0tK7_fxnig%40mail.gmail.com > <https://groups.google.com/d/msgid/elasticsearch/CAFVUaqO9zccHa-EO0e_75_B9ZNDuF_RVCBkn9OLs0tK7_fxnig%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAF3ZnZ%3Dd1%3DhO_mozsX%3D_4%3DL%2B_6CFwcpOvR%2BtbmxLQofyu-37Mw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
