elasticsearch集群生产环境问题及解决，

elasticsearch集群生产环境问题及解决，

          1、oom错误

           集群运行了一段时间后，就出现了oom错误，甚至有的节点的内存都被占满，服务器都无法登陆。

          原因：默认情况下elasticsearch对字段数据缓存是没有限制的，会一直占用内存，直到内存用完

          解决方法：1、设置es的缓存类型为Soft Reference，在配置文件中增加 index.cache.field.type: soft

                              2、设置es最大缓存数据条数和缓存失效时间，通过设置index.cache.field.max_size: 50000来把缓存field的最大值设置为50000，设置index.cache.field.expire: 10m把过期时间设置成10分钟。

        2、heap size设置

        因为es服务器内存是64g，最初按照官方的说法，分了总内存的一半作为es的heapsize，后来才发现这样做是有问题的。

       因为java在堆上分配对象实例，并有一个指针（OOP）指向它们，oop的大小依赖于操作系统32位或64位。这些指针指向数据的每个byte的准确位置，对于32位系统来说，最大的heap size只能是4g。所以java使用了compressed oops来解决这个问题，指向对象实例的偏移量，而不是没一个byte，所以32位指针的heap可以增长到32g。一旦设置超过32g的heapsize，java就会使用oop，所以heapsize的设置不要超过32g。

      那么怎么看是不是使用了compressed oops呢？

   $ JAVA_HOME=`/usr/libexec/java_home -v 1.8` java -Xmx32766m -XX:+PrintFlagsFinal 2> /dev/null | grep UseCompressedOops
     bool UseCompressedOops   := true
   $ JAVA_HOME=`/usr/libexec/java_home -v 1.8` java -Xmx32767m -XX:+PrintFlagsFinal 2> /dev/null | grep UseCompressedOops
     bool UseCompressedOops   = false

       在2.2.0版本起，可以在es日志里看到是否适应了compressed oops

   [2015-12-16 13:53:33,417][INFO ][env] [Illyana Rasputin] heap size [989.8mb], compressed ordinary object pointers [true]

       如果你的服务器有超大的内存，比如128g，启动多个jvm，每个jvm分配的heap size 小于32g，要好过分配一个超大的内存（如 64g）给es