# Put Mapping call -- performance blow?

**URL:** <https://discuss.elastic.co/t/put-mapping-call-performance-blow/14329>\
**Category:** Elasticsearch\
**Created:** [November 8, 2013, 7:08pm UTC](https://discuss.elastic.co/t/put-mapping-call-performance-blow/14329 "2013-11-08T19:08:24Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Antek\_Piechnik](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/antek_piechnik/32/1989_2.png) [@Antek\_Piechnik](https://discuss.elastic.co/u/Antek_Piechnik)\
**Post date:** [November 8, 2013, 7:08pm UTC](https://discuss.elastic.co/t/put-mapping-call-performance-blow/14329/1 "2013-11-08T19:08:24Z")

</div>

Hi,

I'm trying to debug a performance blow that we've had in our ES cluster  
today and I was wondering if updating a mapping could have caused this ?

So I've got a cluster of 5 nodes, 10 indices, out of which 2 quite huge.  
One is 300 shards, the other 100 shards, both with 2 replicas everywhere.  
Those two indices contain about 40M documents in total.  
I use custom routing for all calls. And it's been performing great.

Today I essentially added a new multi\_field with a new analyzer for both  
indices using the Put Mapping API:

url -XPUT '[http://localhost:9200/](http://localhost:9200/)/document/\_mapping' -d '  
{  
"document" : {  
"properties" : {  
"name": {  
"type": "multi\_field",  
"fields": {  
"name": { "type": "string", "index": "not\_analyzed" },  
"sortable": { "type": "string", "analyzer": "sortable" }  
}  
}  
}  
}  
}  
'

At first I couldn't really spot anything happening, but after some time,  
when we've had more and more requests of different kind,  
ElasticSearch started responding extremely slowly. We've never experienced  
a slowdown of this kind. It lasted for about 20minutes, after which it  
stopped and everything is back to normal.

Do you have any thoughts ? Could updating the mapping create a performance  
hit of this kind ?

Regards,  
Antek

--  
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+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).  
For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).

---

<div class="post-metadata">

**Author:** ![jpountz](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jpountz/32/45836_2.png) [@jpountz](https://discuss.elastic.co/u/jpountz)\
**Post date:** [November 12, 2013, 1:48pm UTC](https://discuss.elastic.co/t/put-mapping-call-performance-blow/14329/2 "2013-11-12T13:48:10Z")

</div>

Hi,

My guess would be that the changes you performed in your mappings had  
impact on field data. So maybe this change made field data grow enough to  
come close the the JVM heap capacity, and the garbage collector had to run  
all the time in order to find space for the newly allocated objects. It  
would be interesting to try to correlate your problem with GC activity or  
heap size. If garbage collection is actually the problem, then the solution  
is to either to increase the heap size on your nodes or to add more  
machines so that a single server needs to handle fewer shards.

On Fri, Nov 8, 2013 at 8:08 PM, Antek Piechnik [antek.piechnik@gmail.com](mailto:antek.piechnik@gmail.com)wrote:

> Hi,
> 
> I'm trying to debug a performance blow that we've had in our ES cluster  
> today and I was wondering if updating a mapping could have caused this ?
> 
> So I've got a cluster of 5 nodes, 10 indices, out of which 2 quite huge.  
> One is 300 shards, the other 100 shards, both with 2 replicas everywhere.  
> Those two indices contain about 40M documents in total.  
> I use custom routing for all calls. And it's been performing great.
> 
> Today I essentially added a new multi\_field with a new analyzer for both  
> indices using the Put Mapping API:
> 
> url -XPUT '[http://localhost:9200/](http://localhost:9200/)/document/\_mapping' -d '  
> {  
> "document" : {  
> "properties" : {  
> "name": {  
> "type": "multi\_field",  
> "fields": {  
> "name": { "type": "string", "index": "not\_analyzed" },  
> "sortable": { "type": "string", "analyzer": "sortable" }  
> }  
> }  
> }  
> }  
> }  
> '
> 
> At first I couldn't really spot anything happening, but after some time,  
> when we've had more and more requests of different kind,  
> Elasticsearch started responding extremely slowly. We've never experienced  
> a slowdown of this kind. It lasted for about 20minutes, after which it  
> stopped and everything is back to normal.
> 
> Do you have any thoughts ? Could updating the mapping create a performance  
> hit of this kind ?
> 
> Regards,  
> Antek
> 
> --  
> 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+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).  
> For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).

--  
Adrien Grand

--  
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+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).  
For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [July 6, 2017, 2:07am UTC](https://discuss.elastic.co/t/put-mapping-call-performance-blow/14329/3 "2017-07-06T02:07:41Z")

</div>