1.1 常见配置

1.2 线程池配置

1.2.1 配置值

大小建议和 cpu 的逻辑数（物理CPU个数 每颗物理CPU的核数 超线程数）保持一致。另外，可以通过查看 reject 值查看当前线程数是否合理，若 reject 大于0，则说明线程数或 queue 过小。当某个线程池active==threads时，表示所有线程都在忙，那么后续新的请求就会进入queue中，即queue>0，一旦queue大小超出限制，那么elasticsearch进程将拒绝请求，相应的拒绝次数就会累加到rejected中。queue值建议先使用默认配置，因为queue 值过小会导致请求被拒绝，queue 值很大虽然能保证请求不被拒绝，但是 queue 中请求过多将导致请求在 queue 中排队时间过长，响应时间长，用户体验差。建议根据系统负载和 reject 数以及响应时间来进行动态调整。即：（1）如果 reject=0,则无需调整或适当调低线程数；（2）如果 reject>0，系统负载低，则增加线程数；（3）如果 reject>0,系统负载高，但用户响应时间可以稍微延长，则可以调大 queue 值。（4）如果 reject>0,系统负载高，但用户响应时间不能延长，则只能通过 XYZ（使用更高配置的机器，降低单机应用数，数据切分） 三个方向扩展理论来解决。

1.2.2 配置步骤

修改 elasticsearch.yml 配置文件，增加以下配置，创建索引，并进行检索，使用http://192.168.159.250:9200/_nodes/stats?pretty URL 查询性能参数，如下图所示。由于将线程池为 设置为1，queue 长度设置为 2，索引按照默认配置了 5 分片，同时启动了 5个查询任务并发查询，所以 rejected 数为2。

threadpool.search.type: fixed
threadpool.search.size: 1
threadpool.search.queue_size: 2

2. 系统配置

2.1 最大打开文件数

2.2.1 配置值

最大打开文件数是一个操作系统的配置，默认值为 1024，当socker 连接数过多时，会报“too many open files”错误，这时就需要增加系统最大文件打开数。需要注意，最大打开文件数并非越多越好，该值的主要作用是为了限制外部对操作系统的 socker 连接数，从而控制系统的负载。所以，在系统报 “too many open files”错误时，首先查看系统负载参数（例如 CPU、内存、磁盘 IO 和网络带宽）是否都处于较低的负载状态，再调大最大打开文件数。

2.2.2 配置步骤

修改方法如下： （1）修改前，系统默认的 open files 为1024，此时启动 es 会提示文件数为 1024，建议为65536。 （2）修改 /etc/security/limits.conf 配置文件。 （3）使用 ulimit –a 命令查看open files 为65536，若不生效，则重启后再查看。启动 es，此时最大打开文件数为 65535。

2.2 堆内存大小配置

2.2.1 配置值

官方对堆内存大小的限制不大于机器内存的一半，并且低于 32G，所以，在内存资源不紧张的时候，可以将内存设置为 30G，如果内存资源不足，可以降低到 10G。针对排序、聚合操作多，数据量大的场景，可以测试调大堆内存对性能是否有提升作用。

2.2.2 配置步骤

修改方法，修改环境MAX_HEAP_SIZE 变量，可通过 export 命令或修改 ~/.bashrc 或 /etc/profile 文件实现，建议使用后者，在机器重启后仍然能保持配置。重启 es 服务，使用 jps –v 命令查看是否设置成功。

3. 分片数和副本数设置

分片数和副本数的设置不能一概而论，必须根据集群状态、数据量和应用场景进行调节。首先需要清楚，分片的目的是为了针对同一个索引，使用集群资源进行并发查询，降低大索引查询的响应时间。同时，对于带 filter 的查询，如果分片键设置得当，查询可以仅仅针对命中的分片。 多副本的目的首先是保证数据高可用性，同时进行负载均衡。但需要考虑多副本间数据同步带来的成本。所以，在场景以读为主，且数据量不高的情况下（参考数据量与集群总存储量的比值）可以使用多副本。分片数在创建索引后不可变，副本数是可以根据后期业务动态调整。所以，在创建索引的时候，需要考虑到数据的最大规模和集群规模，通过测试，发现6亿条推文记录，每个分片的大小在 2千万——4千万之间性能查询性能远远优于其他场景。