ES集群重启过程中，出现OOM错误

公司服务器升级，要将原来服务器上ES的数据迁移到新的服务器上去。按照以往的经验，将原来ES的/data目录下的数据复制到新的ES集群下的/data目录，然后等新集群重启完成就可以了。但是这次却遇到了意外状况，新的集群重启过程中，出现了如下错误：

[ERROR][o.e.b.ElasticsearchUncaughtExceptionHandler] [] fatal error in thread [elasticsearch[3Iw-Zj9][clusterService#updateTask][T#1]], exiting
java.lang.OutOfMemoryError: unable to create new native thread
	at java.lang.Thread.start0(Native Method) ~[?:1.8.0_201]
	at java.lang.Thread.start(Thread.java:717) ~[?:1.8.0_201]
	at java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:957) ~[?:1.8.0_201]
	at java.util.concurrent.ThreadPoolExecutor.processWorkerExit(ThreadPoolExecutor.java:1025) ~[?:1.8.0_201]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167) ~[?:1.8.0_201]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) ~[?:1.8.0_201]
	at java.lang.Thread.run(Thread.java:748) [?:1.8.0_201]

显然，问题原因在于ES在启动时创建了太多线程导致内存不足。我们知道，线程不在堆内存上创建，而在堆内存之外的内存上创建。一个系统能创建的最大线程数，可以由经验公式估算：线程数量=（机器可用内存-JVM分配的堆内存）/Xss的值，Xss（Java thread stack size）指的是线程栈占用空间，Linux系统下默认是1M。由公式可以看出，给JVM分配的内存越多，能创建的线程就越少，越容易发生上述错误。

由此看来，似乎是只需要减少ES的堆内存就能解决问题了，但是实际操作后，依然会发生此错误。除了内存配置的原因外，一些内核参数设置不合理也可能导致上述报错。

vm.max_map_count 是 Linux系统中的一个重要参数，决定了一个进程可以拥有的最大内存映射区域数，也会间接影响线程的创建。内存映射是一种将文件或设备映射到进程的地址空间的技术。通过内存映射，应用程序可以将文件或设备的内容直接加载到内存中，从而更高效地访问数据。这个参数对于ES特别重要，因为ES在运行时会创建大量的内存映射。vm.max_map_count的默认值为65530，建议至少设置为262144。除此之外，ulimit -v 和ulimit -m的结果都应该是unlimited。

修改vm.max_map_count 的值后再重启ES，不再出现OOM的错误。

参考资料：https://blog.thetaphi.de/2012/07/use-lucenes-mmapdirectory-on-64bit.html