正式环境中我们一般在只会在一台机器上部署一个ES节点的实例。
在ES中每个es节点内部多有很多个thread pool，不同的thread pool都分担不同的任务，比如有负责查询的，有负责写入的，还有负责执行段合并的，等等。
下面我们就一起来详细了解下ES中的线程池：
2、ES中线程池类型有哪些？
（1）generic thread pool
用于通用操作（例如，后台节点发现）它的线程池类型是动态缩放的
（2）search thread pool
用于count/search/suggest 操作，线程池类型是固定的，默认为cpu core数量 * 3 / 2 + 1，queue大小是1000
（3）write thread pool
用于单个文档的index/delete/update以及bulk请求，线程池类型是固定的，默认为cpu core数量；queue大小是10000。对于大文档我们需要减小这个值，如果大量文本被缓冲到处理队列，会消耗大量堆内存，影响ES集群的正常运行。
（4）get thread pool
用于get 操作，即通过文档id来获取文档信息，线程池类型是固定的，默认为cpu core数量，queue大小是1000
（5）refresh thread pool
用于refresh操作，线程池类型是动态缩放的，获取的是5分钟内10和cpu core数量/2 两者中的最小值；
（6）force merge 操作，线程池类型是固定的，默认为1，queue大小没有限制
（7）flush thread pool
用于?flush?和?translog?fsync?操作，线程池类型是动态缩放的，获取的是5分钟内10和cpu core数量/2 两者中的最小值。
（8）system_read thread pool
用于系统索引的读取，一般是指以“.”开头的索引，比如.security.线程池类型是固定的，默认为5和cpu core数量除以2 这两者中的最小值
（9）system_read thread pool
用于系统索引的写入，线程池类型是固定的，默认为5和cpu core数量除以2 这两者中的最小值
（10） management
用于集群管理，线程池类型是动态缩放的，默认最大大小为5
还有一些比如watcher，system_critical_read，system_critical_write，fetch_shard_store，snapshot等，由于常用用这里就不逐一介绍了。
3、如何设置线程池大小和队列大小？
需要在elasticsearch.yml配置文件中增加下面的配置，比如：
thread_pool: write: size: 30 queue_size: 1000
对于动态类型的线程池设置方式如下：
thread_pool: warmer: core: 1 max: 8 keep_alive: 2m
种线程池数量是可变的，根据负载来变化，最小是cpu core数量，最大是其公式定义，keep_alive参数可以控制其线程空闲多长时间被释放
手动设置cpu core数量
什么情况下需要手动设置CPU 核数呢?
（1）如果在一台机器上运行了多个es节点，但是可能只想要让每个es节点使用部分cpu core，而不是物理机上的所有cpu core，就可以手动设置。比如一台物理机，上面的cpu core是16个，运行了两个es节点，此时就可以手动设置processors是8，就是让每个es节点仅仅使用8个核。
（ 2）默认cpu core的数量最大限制为32个，所以如果我们如果物理机超过了32个cpu core，那么可以手动设置。比如说你的物理机的cpu core是64个，但是此时es会去使用的cpu core可能也就32个，最大限制，此时就是要手动设置processors是64。
（3）有时候可能会捕获到错误的cpu core数量，此时需要手动设置。
怎么设置？
在elasticsearch.yml配置文件中设置
| 1 | processors: 2 |
Elasticsearch 用起来简单，但想要做好还是有很高的技术门槛的。如果你需要用 Go 语言构建搜索服务，并完成海量数据的优化方案，缺乏经验就会有诸多问题暴露，难免走弯路。