Elasticsearch启动常见问题
启动内存问题
Java HotSpot(TM) 64-Bit Server VM warning: INFO: os::commit_memory(0x0000000085330000, 2060255232, 0) failed; error='Cannot allocate memory' (errno=12)
分析: 默认分配的JVM内存为2g，所以当小内存的机器，默认启动的话，会报如上错误。
解决: 修改Eleasticsearch启动JVM内存参数, 修改文件: config/jvm.options
-Xms2g
-Xmx2g
修改为
-Xms1g
-Xmx1g
对于内存较低的云主机和虚拟机，你要测试Elasticsearch的基本功能，没有太大性能要求的话，这时候就需要修改启动内存。
启动用户问题
don't run elasticsearch as root
分析: 程序设计者，出于系统安全考虑设置的条件， 由于ElasticSearch可以接收用户输入的脚本并且执行，为了系统安全考虑，如果获取root权限了，那问题就打了，所以默认官方是建议创建一个单独的用户用来运行ElasticSearch。
解决：添加单独的用户运行
groupadd es
useradd es -g es
更改elasticsearch文件夹及内部文件的所属用户及组为es:es
chown -R es:es elasticsearch
切换到es用户启动：
su - es
./bin/elasticsearch -d
# 或者root下
su es -c "/opt/elasticsearch/bin/elasticsearch -d"
Tips: ES5版本之前，还可以修改
ES_JAVA_OPTS启动参数，加上-Des.insecure.allow.root=true可以使用root启动，但是不推荐这么玩。
最大虚拟内存区域问题
max virtual memory areas vm.max_map_count [256000] is too low, increase to at least [262144]
什么是VMA(virtual memory areas):
This file contains the maximum number of memory map areas a process may have. Memory map areas are used as a side-effect of calling malloc, directly by mmap and mprotect, and also when loading shared libraries.
While most applications need less than a thousand maps, certain programs, particularly malloc debuggers, may consume lots of them, e.g., up to one or two maps per allocation.
The default value is 65536
max_map_count文件包含限制一个进程可以拥有的VMA(虚拟内存区域)的数量。虚拟内存区域是一个连续的虚拟地址空间区域。在进程的生命周期中，每当程序尝试在内存中映射文件，链接到共享内存段，或者分配堆空间的时候，这些区域将被创建。调优这个值将限制进程可拥有VMA的数量。限制一个进程拥有VMA的总数可能导致应用程序出错，因为当进程达到了VMA上线但又只能释放少量的内存给其他的内核进程使用时，操作系统会抛出内存不足的错误。如果你的操作系统在NORMAL区域仅占用少量的内存，那么调低这个值可以帮助释放内存给内核用。
解决:
# 临时设置
sysctl -w vm.max_map_count=262144
# 永久设置
echo "vm.max_map_count=262144" >> /etc/sysctl.conf
sysctl -p
虚拟内存最大大小问题
max size virtual memory [67108864] for user [es] is too low, increase to [unlimited]
分析：引用官网的说法
The segment files that are the components of individual shards and the translog generations that are components of the translog can get large (exceeding multiple gigabytes). On systems where the max size of files that can be created by the Elasticsearch process is limited, this can lead to failed writes. Therefore, the safest option here is that the max file size is unlimited and that is what the max file size bootstrap check enforces. To pass the max file check, you must configure your system to allow the Elasticsearch process the ability to write files of unlimited size.
解决：
echo "* - as unlimited" >> /etc/security/limits.conf
echo "root - as unlimited" >> /etc/security/limits.conf
参考: https://stackoverflow.com/questions/42510873/vm-max-map-count-is-too-low
最大文件描述符问题
max file descriptors [4096] for elasticsearch process is too low, increase to at least [65536]
分析：elasticsearch启动bootstrap checks要求系统打开最大系统文件描述符为65536
解决：
# 临时 ulimit -f unlimited
echo "* soft nofile 65536" >> /etc/security/limits.conf
echo "* hard nofile 65536" >> /etc/security/limits.conf
确认:
ulimit -Hn
ulimit -Sn
最大线程数问题
max number of threads [3818] for user [es] is too low, increase to at least [4096]
分析：elasticsearch启动bootstrap checks要求打开最大线程数最低为4096
解决:
echo "* soft nproc 65535" >> /etc/security/limits.conf
echo "* hard nproc 65535" >> /etc/security/limits.conf
注意：修改这里，普通用户
max user process值是不生效的，需要修改/etc/security/limits.d/20-nproc.conf文件中的值。Centos6系统的是是90-nproc.conf文件。
修改 /etc/security/limits.d/20-nproc.conf
* soft nproc 65535
系统总限制
其实上面的 max user processes 65535 的值也只是表象，普通用户最大进程数无法达到65535 ，因为用户的max user processes的值，最后是受全局的kernel.pid_max的值限制。
也就是说kernel.pid_max=1024 ，那么你用户的max user processes的值是65535 ，用户能打开的最大进程数还是1024。
# 临时生效
echo 65535 > /proc/sys/kernel/pid_max
sysctl -w kernel.pid_max=65535
# 永久生效
echo "kernel.pid_max = 65535" >> /etc/sysctl.conf
sysctl -p
然后重启机器生效。
参考: https://www.cnblogs.com/xidianzxm/p/11820706.html
确认:
ulimit -Hu
ulimit -Su
运行目录权限问题
Exception in thread "main" java.nio.file.AccessDeniedException: /opt/elasticsearch-6.2.2-1/config/jvm.options
分析: es用户没有该文件夹的权限
解决：
chown es.es /opt/elasticsearch-6.2.2-1 -R
如果还有碰到其他问题的同学，可以留言补充。
