elasticsearch 做了下面五点优化:
五点优化
使用 OracleJDK
为什么用 OracleJDK ？
- 业界主要将 OracleJDK 用在生产环境，而 OpenJDK 用在开发环境，而且 OracleJDK 8 会长期支持到 2025 年；
- OracleJDK 性能好于 OpenJDK，原因是 OracleJDK 里的组件都是高性能的组件，而 OpenJDK 出于开源的考量而去掉这些高性能的组件，改为别的开源版本或者是直接去掉。
统一了机器的物理配置
一个机器一个节点，力求每个节点的物理配置一致，避免每个节点的表现不一致的情况。
- 配置 128G 大内存，JVM 优化需要配置到 32G 内，留足内存给 buffer/cache；另外一个原因是机器的 CPU 架构是 NUMA 架构，有两个芯，每个芯分配给 64G 内存，这才能保证每个核都有足够的资源，也给后续一台机部署两套 es 节点后续空间；
- 使用了 SSD 作为数据存储盘， es 的数据索引是以文件的形式存储到硬盘上，索引文件的段 segment 才会存储到内存里，所以用 SSD 可以大幅度优化查询速度，同时也会提高读写数据的速度，加速响应；同时，对于很少对数据进行更改的业务场景来说，就会带来更少的 SSD 重新擦写，使得寿命更长。
采用最新版本
Elasticsearch 以前是5.6.3，现在是6.2.4。这个是必须的，新版本尤其是大版本的更新通常是会伴有性能优化等内容。
调整配置项
limit 配置：
# Disabling Swapping
LimitMEMLOCK=infinity
# Specifies the maximum file descriptor number that can be opened by this process
LimitNOFILE=1048575
# Specifies the maximum number of processes
LimitNPROC=4096
# Specifies the maximum size of virtual memory
LimitAS=infinity
# Specifies the maximum file size
LimitFSIZE=infinity配置 31G JVM heap space
-Xms31g
-Xmx31g服务发现配置：
discovery.zen.ping_timeout: 30s
discovery.zen.fd.ping_interval: 10s
discovery.zen.fd.ping_timeout: 60s
discovery.zen.fd.ping_retries: 6定期清除 cache 和 page
执行下面命令，每小时定时清理内存，需要注意的是，每台节点机器，不要都配置到0分处理，要随机分开处理
echo '0 * * * * /usr/bin/sync && /usr/bin/echo 3 > /proc/sys/vm/drop_caches' > /var/spool/cron/root优化效果：
给 API 带来效果：
明显 api 查询耗时毛刺磨平了，平均耗时在 200ms 以下，最大耗时也在 6s 以下，未优化前的平均耗时出现 6s 的毛刺，最大耗时也出现 60s 的毛刺。
总结：查询耗时大幅度下降，性能毛刺也被磨平。
给分析服务带来效果：
监听服务：
保存耗时由以前的 20~50ms 缩短到现在 3~10ms
分析服务：
观察日志，发现分析耗时基本上都是在 50ms 内完成分析，最慢也在 1s 内完成分析。
总结：分析和监听服务也不再有性能毛刺，分析条件获取也非常快，分析结果保存也非常快。
👊 收官~
本文由 Chakhsu Lau 创作，采用 知识共享署名4.0 国际许可协议进行许可。
本站文章除注明转载/出处外，均为本站原创或翻译，转载前请务必署名。