The current implementation uses the Search pool counter.
We could use the Prefix pool counter but I'm not sure it will work well since we can run 2 queries in the same lock.
I don't know yet how to tune the values of this new pool counter, we could maybe start with 600 and monitor carefully what happens during spikes, compare the elastic threadpools queue and the poolcounter queue.
Description
Description
Details
Details
Related Changes in Gerrit:
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | • Deskana | T121616 EPIC: Resolve technical or product blockers to enable us to do a more full rollout of the completion suggester | |||
| Resolved | EBernhardson | T125547 Use a dedicated pool counter for the CompletionSuggester |
Event Timeline
Comment Actions
Change 268029 had a related patch set uploaded (by EBernhardson):
Create pool counter for CirrusSearch completion suggester
Comment Actions
Change 268030 had a related patch set uploaded (by EBernhardson):
Use completion specific pool counter
Comment Actions
Seems reasonable to start at 600. I do wonder if there should be some interaction between prefix search and completion search pool counters, although i've no clue how to implement it. Basically if the prefix and completion pool counters are full that could mean issues for the cluster. In theory that shouldn't happen, although only in theory :S
Comment Actions
Change 268029 merged by jenkins-bot:
Create pool counter for CirrusSearch completion suggester