Hi @glpadilla_sol I believe "An increase in search tier capacity corresponds to increased search load on the indexing tier, requiring scaling of the indexer nodes." will come from the fact that the total number of searches a SH or cluster can execute at anyone time is determined by the number of CPUs the search head and cluster as a whole have. Using the defaults each search head can execute base_max_searches (6) + number of vCPUs on host x max_searches_per_cpu. These settings are from limits.conf. There are further details for controlling percentage of this value assigned to scheduled and real time searches but I'll put ignore that for now because it isn't relevant here. So if you had 3 search heads each with 8 vCPUs you cluster could execute the following at the same time: = 6 + 8 x 1 = 14 searches x 3 SHs = 42 searches Typically each search takes a single vCPU on each indexer (assuming the data is evenly spread and every indexer responds to every search, which we'd expect) so you'd probably want at least 40/50vCPUs (probably more to account for indexing) on your indexers, if the limits above are being reached in your environment, if you'll never hit the 42 searches executing concurrently then you don't need as many cores on the indexers. Now , if you were to increase the vCPUs on the search heads then you would increase the total number of concurrent searches (unless you changed the values in limits.conf above) that can execute in your environment therefore potentially putting more load onto the indexers and if they didn't have enough vCPUs to handle this increase in search load then it could lead to different issues. Regarding memory, I can't see any reason why increasing the memory on the search head increases the load on the indexers. Your search heads might typically use more memory for searches since that is where the reduce stage of the search occurs so searches that use | dedup or similar can be memory heavy and in that case it may make sense to add more memory to your SHs, if you are typically hitting high percentages of memory usage which you could check via the _introspection index. Thanks, Jamie
... View more