1.es
1. 性能优化的杀手鐗：Filesystem Cache
2. 数据预热
3. 冷热分离
4. ElasticSearch 中的关联查询
5. Document 模型设计
6. 分页性能优化
https://mp.weixin.qq.com/s/kOVrM0lbzwnJ9qnaHjpuuw
- 倒排词典的索引需要常驻内存，无法GC，需要监控data node上segment memory增长趋势。
- 各类缓存，field cache, filter cache, indexing cache, bulk queue等等，要设置合理的大小，并且要应该根据最坏的情况来看heap是否够用，也就是各类缓存全部占满的时候，还有heap空间可以分配给其他任务吗？避免采用clear cache等“自欺欺人”的方式来释放内存。
- 避免返回大量结果集的搜索与聚合。确实需要大量拉取数据的场景，可以采用scan & scroll api来实现。
- cluster stats驻留内存并无法水平扩展，超大规模集群可以考虑分拆成多个集群通过tribe node连接。
- 想知道heap够不够，必须结合实际应用场景，并对集群的heap使用情况做持续的监控。
- 根据监控数据理解内存需求，合理配置各类circuit breaker，将内存溢出风险降低到最低。
原文：https://elasticsearch.cn/article/32
内存、索引、分片、routing、导入、refresh、segments等优化总结
原文：https://blog.csdn.net/qq_19364953/article/details/52161252
https://blog.csdn.net/chenxun_2010/article/details/78602795
参数调优实战
https://blog.csdn.net/ZYC88888/article/details/83184473
2.JVM
java反射的软引用SoftRefLRUPolicyMSPerMB配置为0导致频繁的GC，以及导致GC时间过长
我增加了如下两个JVM启动参数来观察类的加载、卸载信息：-XX:TraceClassLoading -XX:TraceClassUnloading
确定Metaspace增长的元凶是这些类，那么这些类
sun.reflect.GeneratedSerializationConstructorAccessorXXX
出于性能的考虑，JVM会在反射代码执行一定次数后，通过动态生成一些类来将”反射调用”变为“非反射调用”，以达到性能更好。而这些动态生成的类的实例是通过软引用SoftReference来引用的。
我们知道，一个对象只有软引用SoftReference，如果内存空间不足，就会回收这些对象的内存；如果内存空间足够，垃圾回收器不会回收它。只要垃圾回收器没有回收它，该对象就可以被使用。
当GC发生时，以下几个因素影响SoftReference引用的对象是否被回收：
1. SoftReference对象实例多久未访问，通过clock - timestamp得出对象大概有多久未访问；
2. 内存空闲空间的大小；
3. SoftRefLRUPolicyMSPerMB常量值；
是否保留SoftReference引用对象的判断参考表达式，true为不回收，false为回收：
clock - timestamp <= freespace * SoftRefLRUPolicyMSPerMB
说明：
* clock - timestamp：最后一次GC时间和SoftReference对象实例timestamp的属性的差。就是这个SoftReference引用对象大概有多久未访问过了
* freespace：JVMHeap中空闲空间大小，单位为MB。
* SoftRefLRUPolicyMSPerMB：每1M空闲空间可保持的SoftReference对象生存的时长（单位ms）。这个参数就是一个常量，默认值1000，可以通过参数：-XX:SoftRefLRUPolicyMSPerMB进行设置。
查看了一下我们系统的JVM参数配置，发现我们把SoftRefLRUPolicyMSPerMB设置为0了，这样就导致软引用对象很快就被回收了。进而导致需要频繁重新生成这些动态类。
详细文章：https://mp.weixin.qq.com/s/6getqxu1-GCo8hJJl8kG8A
https://mp.weixin.qq.com/s/5H6UHcP6kvR2X5hTj_SBjA?
3.避免redis访问倾斜跟数据倾斜
hot key导致访问倾斜：
1、可以client本地缓存，但是如何判断hot key 以及本地内存的大小，还有本地缓存跟redis的一致性保证等问题需要解决
2、利用分片算法的特性，对key进行打散处理,
所以我们可以给hot key加上前缀或者后缀，把一个hotkey 的数量变成 redis 实例个数N的倍数M，从而由访问一个 redis key 变成访问 N * M 个redis key。
big key导致数据倾斜
对 big key 存储的数据 （big value）进行拆分，变成value1，value2… valueN,
- 如果big value 是个大json 通过 mset 的方式，将这个 key 的内容打散到各个实例中，减小big key 对数据量倾斜造成的影响。
//存
mset key1, vlaue1, key2, vlaue2 ... keyN, valueN
//取
mget key1, key2 ... keyN
- 如果big value 是个大list，可以拆成将list拆成。= list_1， list_2, list3, listN
- 其他数据类型同理。
如果既是hot 又是 big，需要提前预判，进行其他策略结合处理。
更详细参考https://segmentfault.com/a/1190000017387491