id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc	due_date
126	相关配置优化调整	chenchongqi		"本调整也是跟重启负载相关，经过一系列日志的分析，在重启过程中出现过多个引起负载的因素，在卡住的线程里出现过包括lru缓存、r系统、jdbc连接、mc、el表达式甚至spring的getbean等。这些资源相关的线程出现在threaddump里的时候无一例外是，都在block状态等锁一个对象，然后锁住这个对象的线程又在block状态等一个内存的entry，类似以下：
{{{
http-app-a-8081-902$1100619926"" daemon prio=10 tid=0x0000002b6857c400 nid=0x6b78 waiting for monitor entry [0x0000000048ceb000..0x0000000048ceca30]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at javax.el.BeanELResolver.getProps(BeanELResolver.java:308)
        - locked <0x0000002aa9903590> (a java.util.WeakHashMap)
}}}

这个状态一般是在等gc，也就是说可能重启后那几分钟，内存是不够的，从jvm日志也可以证实这点：
{{{
  S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT
 31.62  41.02 100.00  86.86  42.29     82  141.219     5   42.040  183.258
 40.77  41.02 100.00  87.20  42.29     82  141.219     5   42.040  183.258
 48.43  41.02 100.00  87.38  42.29     82  141.219     5   42.040  183.258
}}}

重启的几分钟时间内就5次FGC，相对来说是偏高了。因此有两个方案来缓解，一个是给jvm加内存，一个是减少重启时的内存消耗。调小了mc、mc(R系统的)、xindex(用mc客户端)的初始化连接设置，并且调小了resin的最大线程数，考虑到重启后第一波访问的响应会偏慢(各种初始的操作)，那几分钟基本上线程数是会彪到最大的，这设置会影响那个时候的内存消耗。 

在239.80和239.20上修改后，目测是重启负载高峰虽然还有，但是被监控进程二次重启的情况暂未出现，对重启后的性能恢复有帮助。"	优化	closed	major		报价库	报价库5.0	fixed