架构学习笔记(笔记)

1.es

1. 性能优化的杀手锏:Filesystem Cache

2. 数据预热

3. 冷热分离

4. ElasticSearch 中的关联查询

5. Document 模型设计

6. 分页性能优化

https://mp.weixin.qq.com/s/kOVrM0lbzwnJ9qnaHjpuuw

  1. 倒排词典的索引需要常驻内存,无法GC,需要监控data node上segment memory增长趋势。
  2. 各类缓存,field cache, filter cache, indexing cache, bulk queue等等,要设置合理的大小,并且要应该根据最坏的情况来看heap是否够用,也就是各类缓存全部占满的时候,还有heap空间可以分配给其他任务吗?避免采用clear cache等“自欺欺人”的方式来释放内存。
  3. 避免返回大量结果集的搜索与聚合。确实需要大量拉取数据的场景,可以采用scan & scroll api来实现。
  4. cluster stats驻留内存并无法水平扩展,超大规模集群可以考虑分拆成多个集群通过tribe node连接。
  5. 想知道heap够不够,必须结合实际应用场景,并对集群的heap使用情况做持续的监控。
  6. 根据监控数据理解内存需求,合理配置各类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,

  1. 如果big value 是个大json 通过 mset 的方式,将这个 key 的内容打散到各个实例中,减小big key 对数据量倾斜造成的影响。
//存
mset key1, vlaue1, key2, vlaue2 ... keyN, valueN
//取
mget key1, key2 ... keyN
  1. 如果big value 是个大list,可以拆成将list拆成。= list_1, list_2, list3, listN
  2. 其他数据类型同理。

如果既是hot 又是 big,需要提前预判,进行其他策略结合处理。

更详细参考https://segmentfault.com/a/1190000017387491

 

 

 

 

 

 

 

 

 

 

你可能感兴趣的:(java,面试)