A question about search threadpool size

[rpgmakervx (code4j)]

As org.elasticsearch.threadpool. ExecutorBuilder#applyHardSizeLimit method shown that write threadpool holds a controllable core thread count, default could not over 32.

but search will return an unlimit max size which means that when queue is full, thread will be created ulimitly. So why search threadpopl designed like this?

here's the source code:

[jmorph99 (John Murphy)]

Neither search or indexing uses a scaling thread pool.

https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-threadpool.html

[rpgmakervx (code4j)]

search uses fixed threadpool, whitch means it can reach a huge number of threads。

core size equals to the above applyHardSizeLimit method's result。

[jmorph99 (John Murphy)]

A fixed thread pool means that it limits the number of threads. It will queue up tasks until a thread becomes available. If the queue becomes full it will reject further requests with a 429 error. A scaling thread pool can create unlimited threads.

[rpgmakervx (code4j)]

In version 5.4.1. if someone config thread_pool.search.size=1000(or bigger) by accident , there will be no limit on the maximum number of search threads (applyHardSizeLimit method shown that the max thread could reach Integer.MAX_VALUE)，but if someone set thread_pool.index.size=1024 by accident, the index thread will not exceeding 32。 I mean maybe search thread should also do the same as index thread to protect this human error ?

[jmorph99 (John Murphy)]

Sounds like a 5.4.1 bug.

[DavidTurner]

See Remove artificial default processors limit by jasontedor · Pull Request #20874 · elastic/elasticsearch · GitHub, in particular:

There are some caveats still to having too many concurrent indexing
threads as it can lead to too many little segments...

AIUI this is why the number of indexing threads is more strictly bounded than most of the other thread pools: it leads to non-obvious performance issues that might persist even after the pool size is reduced. On the other hand if you want 1000 search threads and your node can't handle it then it will fail in much more obvious ways.

[rpgmakervx (code4j)]

I found that in recent version, this method in ExecutorBuilder is also unlimit to the search threadool's size.

[rpgmakervx (code4j)]

so I think all kind's of threapool's core size should be limited to protect from oom or other potential danger

[DavidTurner]

I'm wondering why this is of importance to you. If you don't want so many threads, don't ask for so many threads. I can't think of an easy way to choose a limit that protects the cases that need it without unduly limiting the cases that don't. There are other protections against OOMs (in more recent versions anyway) that should help here.

[rpgmakervx (code4j)]

Just as I said, by accident, and some developer might didn't realize this problem。 And on the other hand, I want to know why index/bulk limit thread count but search don't, what will happen if search make this limit.