ES搜索框架--低配置服务器部署ES导致崩溃的解决

发布时间 2023-04-15 18:40:18作者: 脑袋凉凉

省流:修改jvm.options,降低堆大小


一、服务器情况

最近es会突然stop,查看日志后发现经常是因为报错:Native controller process has stopped - no new native processes can be started,无法开启新的进程,可能是由于内存不足--因为服务器内存只有2G,而且仅仅启动es和java项目后就已经占用了97%,一再进行查询等操作,多半完蛋。于是开始查看服务器的内存使用情况:

1.free -m查看整体内存情况

PS:这里启用交换内存,可以把不常用的进程移出内存,本来想通过这种方式来缓解被es占满的内存,但是阅读es的文档后发现官方建议生产环境需要设置bootstrap.memory_lock: true

原因:

发生系统swapping的时候ES节点的性能会非常差,也会影响节点的稳定性。所以要不惜一切代价来避免swapping。swapping会导致Java GC的周期延迟从毫秒级恶化到分钟,更严重的是会引起节点响应延迟甚至脱离集群。

步骤:

要在节点上启用内存锁定,请将以下行添加到每个节点上的 yaml 配置文件中:'bootstrap.memory_lock: true'。该标志会将进程地址空间锁定到 RAM 中,防止任何进程内存被换出。更改每个节点的配置并执行滚动重启。

其他操作:

博客:https://blog.csdn.net/weixin_40392053/article/details/105172673

官方文档:https://www.elastic.co/guide/en/elasticsearch/reference/current/setup-configuration-memory.html

image


2.top查看具体占用情况

输入top后,按m使进程按照内存占用排序,按c使进程按CPU占用排序,按q退出(top –p 进程pid可以查看具体进程的占用情况,pid可以通过端口查询得到:netstat -anp |grep 9200)

列详情:https://blog.csdn.net/sunny_day_day/article/details/119462077

image

image

可以看到res列,即进程当前使用的内存大小,但不包括swap内存(按f进入列的可视化选择,按照介绍选择swap按d选中显示,然后按q退出),swap为0(禁止es交换)

image

image

可以发现es的占用太大,多半是这个原因导致系统内存不足,就把es给关掉了,因此下面想办法进行解决。


二、修改ES配置

1.前人的实践

高配置优化:https://blog.csdn.net/star1210644725/article/details/127035551

低配置部署:https://cloud.tencent.com/developer/article/2065698

image

可以看到在低配置服务器上安装es确实是一个不太妙的选择,但这个暂时解决不了,那么可以修改的就是ES的JVM设置了,具体设置多少呢,参考官方文档:建议保留至少 50% 的机器内存未分配并可供操作系统使用,因为分片查询会利用文件系统缓存。

image


2.修改配置

于是结论就出来了:

image

将es的jvm设置为available的一半,也就是590M,留点余地设为470M:

vim /user/es/elasticsearch-7.10.2/config/jvm.options

image

开启es后:

image

image

暂时服务器方面就这样了,应该不会崩溃了。。后续如果再崩溃或者有性能方面的瓶颈,就考虑提高服务器配置了。