Opinions on using different client nodes for indexing and searching

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

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.

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!

@lwintergerst can you please add the link to the new thread that you have opened? will be really helpful.

Here you go