ES搜索框架--低配置服务器部署ES导致崩溃的解决
省流：修改jvm.options，降低堆大小
一、服务器情况
最近es会突然stop，查看日志后发现经常是因为报错：Native controller process has stopped - no new native processes can be started，无法开启新的进程，可能是由于内存不足--因为服务器内存只有2G，而且仅仅启动es和java项目后就已经占用了97%，一再进行查询等操作，多半完蛋。于是开始查看服务器的内存使用情况：
1.free -m查看整体内存情况
数值详情：https://blog.csdn.net/weixin_42434700/article/details/124249579
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
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
可以看到res列，即进程当前使用的内存大小，但不包括swap内存（按f进入列的可视化选择，按照介绍选择swap按d选中显示，然后按q退出），swap为0（禁止es交换）
可以发现es的占用太大，多半是这个原因导致系统内存不足，就把es给关掉了，因此下面想办法进行解决。
二、修改ES配置
1.前人的实践
高配置优化：https://blog.csdn.net/star1210644725/article/details/127035551
低配置部署：https://cloud.tencent.com/developer/article/2065698
可以看到在低配置服务器上安装es确实是一个不太妙的选择，但这个暂时解决不了，那么可以修改的就是ES的JVM设置了，具体设置多少呢，参考官方文档：建议保留至少 50% 的机器内存未分配并可供操作系统使用，因为分片查询会利用文件系统缓存。
2.修改配置
于是结论就出来了：
将es的jvm设置为available的一半，也就是590M，留点余地设为470M：
vim /user/es/elasticsearch-7.10.2/config/jvm.options
开启es后：
暂时服务器方面就这样了，应该不会崩溃了。。后续如果再崩溃或者有性能方面的瓶颈，就考虑提高服务器配置了。
3.解决提示reason: [shards started [[policy_index][0]]
参考：https://www.jianshu.com/p/491761c66d40
原因：分片太多，节点不够。单机es，1个节点但分片的副本数超过1个了，每个主分片的副本数少于群集中的节点数，所以要调整为0。
curl -XPUT http://127.0.0.1:9200/_settings?pretty -d '{ "index": { "number_of_replicas": 0 } }' -H "Content-Type: application/json"
一些关于此问题的讨论：
https://discuss.circleci.com/t/elasticsearch-container-got-killed/17654
https://github.com/elastic/elasticsearch/issues/25067
