# Decreasing Heap Size Results in Better TPS, How can this happen? **URL:** \ **Category:** Elasticsearch\ **Created:** [February 18, 2015, 6:45pm UTC](https://discuss.elastic.co/t/decreasing-heap-size-results-in-better-tps-how-can-this-happen/22244 "2015-02-18T18:45:22Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![vsrikanth\_chinna](https://avatars.discourse-cdn.com/v4/letter/v/9de053/32.png) [@vsrikanth\_chinna](https://discuss.elastic.co/u/vsrikanth_chinna)\ **Post date:** [February 18, 2015, 6:45pm UTC](https://discuss.elastic.co/t/decreasing-heap-size-results-in-better-tps-how-can-this-happen/22244/1 "2015-02-18T18:45:22Z")
We have 5 shards(give each size) totaling to 76.6GB in a single host c3.8xlarge [http://aws.amazon.com/ec2/instance-types/](http://aws.amazon.com/ec2/instance-types/) system (60gb ram, 32 core, 2\*320 SSD ) We have multiple fields in our record, but single field is ngram analyzed on which we search results for. This search need to performed on all 5 shards of the host to get results, as there is no routing in our case. We observed huge variations in search TPS with _decrease_ in elastic search heap memory size. Attached bigdesk images for both of the below cases! CASE1) When ess\_heap size = 16gb Search tps observed is 50 CASE2) When ess\_heap\_size=30gb Search tps observed is 18 Surprising thing is as we decrease ess\_heap\_size the search tps got increased. All the resources(cpu,memory etc) are not fully utilized, OS heap memory is not changed much, observed lot of zig zag ess\_heap usage(increase and decrease of ess heap usage, may be because of high index size that need to be brought to RAM) and reads I/Os followed same zig zag manner in both the cases. Please note that we have run this experiment _multiple_ times and observed the same pattern. Can you please guide on what is going wrong? what dec ess\_heap increasing the tps, should we further decrease to achieve better tps or we doing something wrong? -Thanks Srikanth V. -- 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). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/f1d1bf51-ab4d-4242-94e5-4b5c3adf466c%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/f1d1bf51-ab4d-4242-94e5-4b5c3adf466c%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![jprante](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jprante/32/44941_2.png) [@jprante](https://discuss.elastic.co/u/jprante)\ **Post date:** [February 18, 2015, 7:24pm UTC](https://discuss.elastic.co/t/decreasing-heap-size-results-in-better-tps-how-can-this-happen/22244/2 "2015-02-18T19:24:14Z")
So you believe in "the more heap the better"? This assumption you have just proved wrong. Note, in your test, at 16GB heap, GC took half a second, while at 30GB heap, GC took around a second (and maybe more overhead in stop-the-world pauses). This is a hint about current JVM GC scalability of Java 7. Jörg On Wed, Feb 18, 2015 at 7:45 PM, Srikanth Valiveti \< [vsrikanth.chinna@gmail.com](mailto:vsrikanth.chinna@gmail.com)\> wrote: > We have 5 shards(give each size) totaling to 76.6GB in a single host > c3.8xlarge [http://aws.amazon.com/ec2/instance-types/](http://aws.amazon.com/ec2/instance-types/) system (60gb ram, > 32 core, 2\*320 SSD ) > > We have multiple fields in our record, but single field is ngram analyzed > on which we search results for. This search need to performed on all 5 > shards of the host to get results, as there is no routing in our case. > > We observed huge variations in search TPS with _decrease_ in elastic > search heap memory size. Attached bigdesk images for both of the below > cases! > > CASE1) > When ess\_heap size = 16gb > Search tps observed is 50 > > CASE2) > When ess\_heap\_size=30gb > Search tps observed is 18 > > Surprising thing is as we decrease ess\_heap\_size the search tps got > increased. All the resources(cpu,memory etc) are not fully utilized, OS > heap memory is not changed much, observed lot of zig zag ess\_heap > usage(increase and decrease of ess heap usage, may be because of high index > size that need to be brought to RAM) and reads I/Os followed same zig zag > manner in both the cases. > > Please note that we have run this experiment _multiple_ times and > observed the same pattern. Can you please guide on what is going wrong? > what dec ess\_heap increasing the tps, should we further decrease to achieve > better tps or we doing something wrong? > > -Thanks > Srikanth V. > > -- > 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). > To view this discussion on the web visit > [https://groups.google.com/d/msgid/elasticsearch/f1d1bf51-ab4d-4242-94e5-4b5c3adf466c%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/f1d1bf51-ab4d-4242-94e5-4b5c3adf466c%40googlegroups.com) > [https://groups.google.com/d/msgid/elasticsearch/f1d1bf51-ab4d-4242-94e5-4b5c3adf466c%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/f1d1bf51-ab4d-4242-94e5-4b5c3adf466c%40googlegroups.com?utm_medium=email&utm_source=footer) > . > For more options, visit [https://groups.google.com/d/optout](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 [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAKdsXoEpT8rNM5%2BosX%3D2%2B70RF-A12ujT2bw3ak4LcH5aQhCA%3DQ%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAKdsXoEpT8rNM5%2BosX%3D2%2B70RF-A12ujT2bw3ak4LcH5aQhCA%3DQ%40mail.gmail.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![krishna](https://avatars.discourse-cdn.com/v4/letter/k/71c47a/32.png) [@krishna](https://discuss.elastic.co/u/krishna)\ **Post date:** [February 18, 2015, 8:50pm UTC](https://discuss.elastic.co/t/decreasing-heap-size-results-in-better-tps-how-can-this-happen/22244/3 "2015-02-18T20:50:57Z")
They are couple of questions pertaining to above graphs 1. Yes the GC time taken is doubled, but the (frequency)rate of GC cycle is high(almost double/triple) in 16gb compared to 30gb. 2. Why complete memory is not utilized before cleaning up the memory, for eg for 30gb, maximum usage is around 20gb, for 16gb it is 11gb. 3. This looks like thrashing!, is it because of large index size(76.6GB) on single host ?, PS: GC used here is G1GC On Thursday, 19 February 2015 00:54:25 UTC+5:30, Jörg Prante wrote: > So you believe in "the more heap the better"? This assumption you have > just proved wrong. Note, in your test, at 16GB heap, GC took half a second, > while at 30GB heap, GC took around a second (and maybe more overhead in > stop-the-world pauses). This is a hint about current JVM GC scalability of > Java 7. > > Jörg > > On Wed, Feb 18, 2015 at 7:45 PM, Srikanth Valiveti \<[vsrikant...@gmail.com](mailto:vsrikant...@gmail.com) > \\> wrote: > > > We have 5 shards(give each size) totaling to 76.6GB in a single host > > c3.8xlarge [http://aws.amazon.com/ec2/instance-types/](http://aws.amazon.com/ec2/instance-types/) system (60gb ram, > > 32 core, 2\*320 SSD ) > > > > We have multiple fields in our record, but single field is ngram analyzed > > on which we search results for. This search need to performed on all 5 > > shards of the host to get results, as there is no routing in our case. > > > > We observed huge variations in search TPS with _decrease_ in elastic > > search heap memory size. Attached bigdesk images for both of the below > > cases! > > > > CASE1) > > When ess\_heap size = 16gb > > Search tps observed is 50 > > > > CASE2) > > When ess\_heap\_size=30gb > > Search tps observed is 18 > > > > Surprising thing is as we decrease ess\_heap\_size the search tps got > > increased. All the resources(cpu,memory etc) are not fully utilized, OS > > heap memory is not changed much, observed lot of zig zag ess\_heap > > usage(increase and decrease of ess heap usage, may be because of high index > > size that need to be brought to RAM) and reads I/Os followed same zig zag > > manner in both the cases. > > > > Please note that we have run this experiment _multiple_ times and > > observed the same pattern. Can you please guide on what is going wrong? > > what dec ess\_heap increasing the tps, should we further decrease to achieve > > better tps or we doing something wrong? > > > > -Thanks > > Srikanth V. > > > > -- > > 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 [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com) \. > > To view this discussion on the web visit > > [https://groups.google.com/d/msgid/elasticsearch/f1d1bf51-ab4d-4242-94e5-4b5c3adf466c%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/f1d1bf51-ab4d-4242-94e5-4b5c3adf466c%40googlegroups.com) > > [https://groups.google.com/d/msgid/elasticsearch/f1d1bf51-ab4d-4242-94e5-4b5c3adf466c%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/f1d1bf51-ab4d-4242-94e5-4b5c3adf466c%40googlegroups.com?utm_medium=email&utm_source=footer) > > . > > For more options, visit [https://groups.google.com/d/optout](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 [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/8aea6643-0fe8-43e0-a698-8379e306d21e%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/8aea6643-0fe8-43e0-a698-8379e306d21e%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![mikemccand](https://avatars.discourse-cdn.com/v4/letter/m/f04885/32.png) [@mikemccand](https://discuss.elastic.co/u/mikemccand)\ **Post date:** [February 18, 2015, 9:36pm UTC](https://discuss.elastic.co/t/decreasing-heap-size-results-in-better-tps-how-can-this-happen/22244/4 "2015-02-18T21:36:39Z")
Smaller JVM heap means more free RAM for the OS to cache hot pages from your index ... in general you should only give the JVM as much as it needs (will ever need) and a bit more for safety, and give the rest to the OS so it can put hot parts of your index in RAM. Mike McCandless [http://blog.mikemccandless.com](http://blog.mikemccandless.com) On Wed, Feb 18, 2015 at 3:50 PM, sri krishna [krishnainet@gmail.com](mailto:krishnainet@gmail.com) wrote: > They are couple of questions pertaining to above graphs > > 1. Yes the GC time taken is doubled, but the (frequency)rate of GC cycle > is high(almost double/triple) in 16gb compared to 30gb. > > 2. Why complete memory is not utilized before cleaning up the memory, for > eg for 30gb, maximum usage is around 20gb, for 16gb it is 11gb. > > 3. This looks like thrashing!, is it because of large index size(76.6GB) > on single host ?, > > PS: GC used here is G1GC > > On Thursday, 19 February 2015 00:54:25 UTC+5:30, Jörg Prante wrote: > > > So you believe in "the more heap the better"? This assumption you have > > just proved wrong. Note, in your test, at 16GB heap, GC took half a second, > > while at 30GB heap, GC took around a second (and maybe more overhead in > > stop-the-world pauses). This is a hint about current JVM GC scalability of > > Java 7. > > > > Jörg > > > > On Wed, Feb 18, 2015 at 7:45 PM, Srikanth Valiveti \<[vsrikant...@gmail.com](mailto:vsrikant...@gmail.com) > > > > > wrote: > > > > > We have 5 shards(give each size) totaling to 76.6GB in a single host > > > c3.8xlarge [http://aws.amazon.com/ec2/instance-types/](http://aws.amazon.com/ec2/instance-types/) system (60gb > > > ram, 32 core, 2\*320 SSD ) > > > > > > We have multiple fields in our record, but single field is ngram > > > analyzed on which we search results for. This search need to performed on > > > all 5 shards of the host to get results, as there is no routing in our case. > > > > > > We observed huge variations in search TPS with _decrease_ in elastic > > > search heap memory size. Attached bigdesk images for both of the below > > > cases! > > > > > > CASE1) > > > When ess\_heap size = 16gb > > > Search tps observed is 50 > > > > > > CASE2) > > > When ess\_heap\_size=30gb > > > Search tps observed is 18 > > > > > > Surprising thing is as we decrease ess\_heap\_size the search tps got > > > increased. All the resources(cpu,memory etc) are not fully utilized, OS > > > heap memory is not changed much, observed lot of zig zag ess\_heap > > > usage(increase and decrease of ess heap usage, may be because of high index > > > size that need to be brought to RAM) and reads I/Os followed same zig zag > > > manner in both the cases. > > > > > > Please note that we have run this experiment _multiple_ times and > > > observed the same pattern. Can you please guide on what is going wrong? > > > what dec ess\_heap increasing the tps, should we further decrease to achieve > > > better tps or we doing something wrong? > > > > > > -Thanks > > > Srikanth V. > > > > > > -- > > > 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 [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com). > > > To view this discussion on the web visit [https://groups.google.com/d/](https://groups.google.com/d/) > > > msgid/elasticsearch/f1d1bf51-ab4d-4242-94e5-4b5c3adf466c% > > > [40googlegroups.com](http://40googlegroups.com) > > > [https://groups.google.com/d/msgid/elasticsearch/f1d1bf51-ab4d-4242-94e5-4b5c3adf466c%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/f1d1bf51-ab4d-4242-94e5-4b5c3adf466c%40googlegroups.com?utm_medium=email&utm_source=footer) > > > . > > > For more options, visit [https://groups.google.com/d/optout](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 [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > > To view this discussion on the web visit > > [https://groups.google.com/d/msgid/elasticsearch/8aea6643-0fe8-43e0-a698-8379e306d21e%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/8aea6643-0fe8-43e0-a698-8379e306d21e%40googlegroups.com) > > [https://groups.google.com/d/msgid/elasticsearch/8aea6643-0fe8-43e0-a698-8379e306d21e%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/8aea6643-0fe8-43e0-a698-8379e306d21e%40googlegroups.com?utm_medium=email&utm_source=footer) > > . > > For more options, visit [https://groups.google.com/d/optout](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 [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAD7smReTN-1oScpc%2BU4OLGGd\_hAQPLjR0YED%2BLbwp%2Bnbxp80Gw%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAD7smReTN-1oScpc%2BU4OLGGd_hAQPLjR0YED%2BLbwp%2Bnbxp80Gw%40mail.gmail.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![vsrikanth\_chinna](https://avatars.discourse-cdn.com/v4/letter/v/9de053/32.png) [@vsrikanth\_chinna](https://discuss.elastic.co/u/vsrikanth_chinna)\ **Post date:** [February 19, 2015, 3:40am UTC](https://discuss.elastic.co/t/decreasing-heap-size-results-in-better-tps-how-can-this-happen/22244/5 "2015-02-19T03:40:35Z")
We thought the same about the OS cache, but it was proved to be wrong as the graphs for the os cache usage seems to be almost same in both the cases. On Thu, Feb 19, 2015 at 3:06 AM, Michael McCandless [mike@elasticsearch.com](mailto:mike@elasticsearch.com) wrote: > Smaller JVM heap means more free RAM for the OS to cache hot pages from > your index ... in general you should only give the JVM as much as it needs > (will ever need) and a bit more for safety, and give the rest to the OS so > it can put hot parts of your index in RAM. > > Mike McCandless > > [http://blog.mikemccandless.com](http://blog.mikemccandless.com) > > On Wed, Feb 18, 2015 at 3:50 PM, sri krishna [krishnainet@gmail.com](mailto:krishnainet@gmail.com) > wrote: > > > They are couple of questions pertaining to above graphs > > > > 1. Yes the GC time taken is doubled, but the (frequency)rate of GC cycle > > is high(almost double/triple) in 16gb compared to 30gb. > > > > 2. Why complete memory is not utilized before cleaning up the memory, for > > eg for 30gb, maximum usage is around 20gb, for 16gb it is 11gb. > > > > 3. This looks like thrashing!, is it because of large index size(76.6GB) > > on single host ?, > > > > PS: GC used here is G1GC > > > > On Thursday, 19 February 2015 00:54:25 UTC+5:30, Jörg Prante wrote: > > > > > So you believe in "the more heap the better"? This assumption you have > > > just proved wrong. Note, in your test, at 16GB heap, GC took half a second, > > > while at 30GB heap, GC took around a second (and maybe more overhead in > > > stop-the-world pauses). This is a hint about current JVM GC scalability of > > > Java 7. > > > > > > Jörg > > > > > > On Wed, Feb 18, 2015 at 7:45 PM, Srikanth Valiveti \< > > > [vsrikant...@gmail.com](mailto:vsrikant...@gmail.com)\> wrote: > > > > > > > We have 5 shards(give each size) totaling to 76.6GB in a single host > > > > c3.8xlarge [http://aws.amazon.com/ec2/instance-types/](http://aws.amazon.com/ec2/instance-types/) system (60gb > > > > ram, 32 core, 2\*320 SSD ) > > > > > > > > We have multiple fields in our record, but single field is ngram > > > > analyzed on which we search results for. This search need to performed on > > > > all 5 shards of the host to get results, as there is no routing in our case. > > > > > > > > We observed huge variations in search TPS with _decrease_ in elastic > > > > search heap memory size. Attached bigdesk images for both of the below > > > > cases! > > > > > > > > CASE1) > > > > When ess\_heap size = 16gb > > > > Search tps observed is 50 > > > > > > > > CASE2) > > > > When ess\_heap\_size=30gb > > > > Search tps observed is 18 > > > > > > > > Surprising thing is as we decrease ess\_heap\_size the search tps got > > > > increased. All the resources(cpu,memory etc) are not fully utilized, OS > > > > heap memory is not changed much, observed lot of zig zag ess\_heap > > > > usage(increase and decrease of ess heap usage, may be because of high index > > > > size that need to be brought to RAM) and reads I/Os followed same zig zag > > > > manner in both the cases. > > > > > > > > Please note that we have run this experiment _multiple_ times and > > > > observed the same pattern. Can you please guide on what is going wrong? > > > > what dec ess\_heap increasing the tps, should we further decrease to achieve > > > > better tps or we doing something wrong? > > > > > > > > -Thanks > > > > Srikanth V. > > > > > > > > -- > > > > 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 [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com). > > > > To view this discussion on the web visit [https://groups.google.com/d/](https://groups.google.com/d/) > > > > msgid/elasticsearch/f1d1bf51-ab4d-4242-94e5-4b5c3adf466c% > > > > [40googlegroups.com](http://40googlegroups.com) > > > > [https://groups.google.com/d/msgid/elasticsearch/f1d1bf51-ab4d-4242-94e5-4b5c3adf466c%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/f1d1bf51-ab4d-4242-94e5-4b5c3adf466c%40googlegroups.com?utm_medium=email&utm_source=footer) > > > > . > > > > For more options, visit [https://groups.google.com/d/optout](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 [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > > > To view this discussion on the web visit > > > [https://groups.google.com/d/msgid/elasticsearch/8aea6643-0fe8-43e0-a698-8379e306d21e%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/8aea6643-0fe8-43e0-a698-8379e306d21e%40googlegroups.com) > > > [https://groups.google.com/d/msgid/elasticsearch/8aea6643-0fe8-43e0-a698-8379e306d21e%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/8aea6643-0fe8-43e0-a698-8379e306d21e%40googlegroups.com?utm_medium=email&utm_source=footer) > > > . > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > -- > 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/sCzgycU8QgE/unsubscribe](https://groups.google.com/d/topic/elasticsearch/sCzgycU8QgE/unsubscribe). > To unsubscribe from this group and all its topics, send an email to > [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > To view this discussion on the web visit > [https://groups.google.com/d/msgid/elasticsearch/CAD7smReTN-1oScpc%2BU4OLGGd\_hAQPLjR0YED%2BLbwp%2Bnbxp80Gw%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAD7smReTN-1oScpc%2BU4OLGGd_hAQPLjR0YED%2BLbwp%2Bnbxp80Gw%40mail.gmail.com) > [https://groups.google.com/d/msgid/elasticsearch/CAD7smReTN-1oScpc%2BU4OLGGd\_hAQPLjR0YED%2BLbwp%2Bnbxp80Gw%40mail.gmail.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/CAD7smReTN-1oScpc%2BU4OLGGd_hAQPLjR0YED%2BLbwp%2Bnbxp80Gw%40mail.gmail.com?utm_medium=email&utm_source=footer) > . > > For more options, visit [https://groups.google.com/d/optout](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 [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CANzRR0VywPB2MYg41dQoj%2Bo49MtTP\_1hudnGNv4TjOfimT7-7Q%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CANzRR0VywPB2MYg41dQoj%2Bo49MtTP_1hudnGNv4TjOfimT7-7Q%40mail.gmail.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**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, 12:31am UTC](https://discuss.elastic.co/t/decreasing-heap-size-results-in-better-tps-how-can-this-happen/22244/6 "2017-07-06T00:31:43Z")