# Best way to take advantage of resources **URL:** \ **Category:** Elasticsearch\ **Created:** [March 6, 2012, 12:59am UTC](https://discuss.elastic.co/t/best-way-to-take-advantage-of-resources/6899 "2012-03-06T00:59:23Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![orenmazor](https://avatars.discourse-cdn.com/v4/letter/o/b782af/32.png) [@orenmazor](https://discuss.elastic.co/u/orenmazor)\ **Post date:** [March 6, 2012, 12:59am UTC](https://discuss.elastic.co/t/best-way-to-take-advantage-of-resources/6899/1 "2012-03-06T00:59:23Z")
hey guys, I have a 40m doc index across two fairly hefty machines (32gb ram, 4core). I do around 100 indexes a second and maybe 30 deletes a second, all in bulk. my settings are as follows: "index.number\_of\_replicas": "0", "index.number\_of\_shards": "10", "index.merge.policy.segments\_per\_tier": "30", "index.refresh\_interval": "3s", "index.merge.policy.max\_merge\_at\_once": "10" I find I still see delays whenever my indexing spikes to around 500-1000/second, and I'm wondering what I can do take better use of these two nodes. the load on them is almost negligible at pretty much all times. one thing I was thinking of doing is starting one or two more nodes on the same machine, and move some of those shards across (I use routing) to maybe help out with indexing that way. thoughts? ---
**Author:** ![Radu\_Gheorghe1](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/radu_gheorghe1/32/2688_2.png) [@Radu\_Gheorghe1](https://discuss.elastic.co/u/Radu_Gheorghe1)\ **Post date:** [March 6, 2012, 5:48am UTC](https://discuss.elastic.co/t/best-way-to-take-advantage-of-resources/6899/2 "2012-03-06T05:48:20Z")
Hi, Maybe it would help if you increase the memory allocated to ES. Take a look here for details: > **[Elasticsearch Platform — Find real-time answers at scale](https://www.elastic.co)** > > Power insights and outcomes with the Elasticsearch Platform and AI. See into your data and find answers that matter with enterprise solutions designed to help you build, observe, and protect. Try Elasticsearch free today. On 6 mar., 02:59, Oren Mazor [o...@wildbit.com](mailto:o...@wildbit.com) wrote: > hey guys, > > I have a 40m doc index across two fairly hefty machines (32gb ram, 4core). > I do around 100 indexes a second and maybe 30 deletes a second, all in > bulk. > > my settings are as follows: > "index.number\_of\_replicas": "0", > > "index.number\_of\_shards": "10", > "index.merge.policy.segments\_per\_tier": "30", > "index.refresh\_interval": "3s", > "index.merge.policy.max\_merge\_at\_once": "10" > > I find I still see delays whenever my indexing spikes to around 500-1000/second, and I'm wondering what I can do take better use of these two nodes. the load on them is almost negligible at pretty much all times. > > one thing I was thinking of doing is starting one or two more nodes on the same machine, and move some of those shards across (I use routing) to maybe help out with indexing that way. > > thoughts? ---
**Author:** ![otisg](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/otisg/32/492_2.png) [@otisg](https://discuss.elastic.co/u/otisg)\ **Post date:** [March 6, 2012, 12:55pm UTC](https://discuss.elastic.co/t/best-way-to-take-advantage-of-resources/6899/3 "2012-03-06T12:55:58Z")
Hi, When your indexing pauses, do you know how your JVM (the one ES is in) is behaving in terms of GCing? That's one thing to check. I believe there are a couple of settings that control flushing. Of course, you'll also want to check that it's not the source of your data that is pausing, and not ES. Increasing index.refresh\_interval will help, too. You'll also want to look at your 2 ES nodes and see if it's the CPU or disk IO or network IO or JVM heap that's the bottleneck and based on that you will know what options may have a positive effect. We haven't announced SPM for Elasticsearch just yet and have not polished it completely, but you are welcome to use our SPM for Elasticsearch tool/service (it's free) that will expose a number of performance metrics from ES and from the underlying JVM and the server itself, so you can more easily tell what's going on with your ES cluster. SPM for ES is hiding at [http://apps.sematext.com/](http://apps.sematext.com/) . ## Otis Hiring Elasticsearch Engineers World-Wide -- > **[Jobs](https://sematext.com/jobs/)** > > We’re Hiring We are always looking for smart, passionate, motivated, and independent people regardless of where on the planet they may be. Learn more about the company Agent & Backend Engineer Full Stack Developer Backend Engineer Frontend... On Tuesday, March 6, 2012 8:59:23 AM UTC+8, Oren Mazor wrote: > hey guys, > > I have a 40m doc index across two fairly hefty machines (32gb ram, 4core). > I do around 100 indexes a second and maybe 30 deletes a second, all in > bulk. > > my settings are as follows: > "index.number\_of\_replicas": "0", > > "index.number\_of\_shards": "10", > "index.merge.policy.segments\_per\_tier": "30", > "index.refresh\_interval": "3s", > "index.merge.policy.max\_merge\_at\_once": "10" > > I find I still see delays whenever my indexing spikes to around 500-1000/second, and I'm wondering what I can do take better use of these two nodes. the load on them is almost negligible at pretty much all times. > > one thing I was thinking of doing is starting one or two more nodes on the same machine, and move some of those shards across (I use routing) to maybe help out with indexing that way. > > thoughts? ---
**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, 3:37am UTC](https://discuss.elastic.co/t/best-way-to-take-advantage-of-resources/6899/4 "2017-07-06T03:37:11Z")