本文共 2141 字，大约阅读时间需要 7 分钟。
1.es
1. 性能优化的杀手锏：Filesystem Cache
2. 数据预热
3. 冷热分离
4. ElasticSearch 中的关联查询
5. Document 模型设计
6. 分页性能优化
原文：
内存、索引、分片、routing、导入、refresh、segments等优化总结
原文：
参数调优实战
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了，这样就导致软引用对象很快就被回收了。进而导致需要频繁重新生成这些动态类。详细文章：
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,
//存mset key1, vlaue1, key2, vlaue2 ... keyN, valueN//取mget key1, key2 ... keyN
如果既是hot 又是 big，需要提前预判，进行其他策略结合处理。
更详细参考
转载地址：http://egadi.baihongyu.com/