# Opinions on using different client nodes for indexing and searching **URL:** \ **Category:** Elasticsearch\ **Created:** [March 31, 2016, 10:23am UTC](https://discuss.elastic.co/t/opinions-on-using-different-client-nodes-for-indexing-and-searching/45913 "2016-03-31T10:23:26Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![lwintergerst](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/lwintergerst/32/18164_2.png) [@lwintergerst](https://discuss.elastic.co/u/lwintergerst)\ **Post date:** [March 31, 2016, 10:23am UTC](https://discuss.elastic.co/t/opinions-on-using-different-client-nodes-for-indexing-and-searching/45913/1 "2016-03-31T10:23:26Z")
Hi, our client nodes are experiencing heavy GC loads recently. We are still trying to pinpoint the problem. In the meantime I was thinking about using a different set of client nodes for indexing and searching. My reasoning is, that even if a giant query kills my "search"-client Node, the "indexer"-client node is still doing well. We are using ELK for the log use case and can live with small downtimes. But if indexing stops for too long we have problems. I was just wondering what your opinions are on this architecture. Luca ---
**Author:** ![javanna](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/javanna/32/4698_2.png) [@javanna](https://discuss.elastic.co/u/javanna)\ **Post date:** [April 1, 2016, 2:50pm UTC](https://discuss.elastic.co/t/opinions-on-using-different-client-nodes-for-indexing-and-searching/45913/2 "2016-04-01T14:50:59Z")
Hi Luca, I guess it all depends on why you have issues on your client nodes. In general, those are lightweight and shouldn't have memory problems as they hold no data, and data (aggregations etc.) is the main responsible for these memory issues. Maybe splitting those up would work around the problem, but it would not really fix it, and it seems a bit of an overkill to me. I would go for trying to find out what is causing the memory problems on the client nodes. ---
**Author:** ![lwintergerst](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/lwintergerst/32/18164_2.png) [@lwintergerst](https://discuss.elastic.co/u/lwintergerst)\ **Post date:** [April 1, 2016, 5:23pm UTC](https://discuss.elastic.co/t/opinions-on-using-different-client-nodes-for-indexing-and-searching/45913/3 "2016-04-01T17:23:47Z")
Yes, you are right. It would only be a work around to another underlying problem. I'm looking for the issue (opened a separate thread) Thanks for the help! ---
**Author:** ![rkalhans](https://avatars.discourse-cdn.com/v4/letter/r/7ea924/32.png) [@rkalhans](https://discuss.elastic.co/u/rkalhans)\ **Post date:** [April 28, 2016, 5:25am UTC](https://discuss.elastic.co/t/opinions-on-using-different-client-nodes-for-indexing-and-searching/45913/4 "2016-04-28T05:25:25Z")
@lwintergerst can you please add the link to the new thread that you have opened? will be really helpful. ---
**Author:** ![lwintergerst](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/lwintergerst/32/18164_2.png) [@lwintergerst](https://discuss.elastic.co/u/lwintergerst)\ **Post date:** [April 28, 2016, 5:41am UTC](https://discuss.elastic.co/t/opinions-on-using-different-client-nodes-for-indexing-and-searching/45913/5 "2016-04-28T05:41:43Z")
Here you go > [@Find out what causes long GC cycles on client node](https://discuss.elastic.co/t/find-out-what-causes-long-gc-cycles-on-client-node/45917/2): > > This might be useful references: For me, it was almost always fielddata. Look for evictions in that and filterdata. \_node/stats and/or marvel or other monitor is your friend for troubleshooting this. If you are not using doc\_values, it can help (at some indexing cost). ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 5, 2017, 10:55pm UTC](https://discuss.elastic.co/t/opinions-on-using-different-client-nodes-for-indexing-and-searching/45913/6 "2017-07-05T22:55:42Z")