搜索降级方案中xmn開始使用bizer默认的128M,很慢。
偶然改成1G,效果立刻上来,可是xmx调大并没有明显效果。
100并发 200并发
10G 53(17.3385) 110(25.7648)
15G 53(17.7007) 111(25.5927)
18G 52(15.98) 112(27.1689)
调大xmn,3G:
48(14.6) 96(21.8455)
5G:
47(15.242) 94(20.5127)
8G:
46(14.5743) 96(20.5468)
3G足已,并发调到400測试:
180(23.7523)
调到5G:
183(24.1582)
3G够支撑400并发,xmx调到8G,看看性能是否下降。
179(22.70)
所以8G也够了。
调整thread count,原来是128,调到50:
177(11.6078)
调到30:
173(8.40206)
看来30个就够了,调整max queue到768(原来512):
167(8.62541)
调到1024:
169(8.69687)
所以还是维持原来的512.
一个经验,对于较少存活对象又要求高并发的。能够用ThreadLocal方式降低大对象的分配。假设没法消除(比方String之类的无法避免大量使用但又不能回首)一定要调大xmn(或new ratio)。
偶然改成1G,效果立刻上来,可是xmx调大并没有明显效果。
100并发 200并发
10G 53(17.3385) 110(25.7648)
15G 53(17.7007) 111(25.5927)
18G 52(15.98) 112(27.1689)
调大xmn,3G:
48(14.6) 96(21.8455)
5G:
47(15.242) 94(20.5127)
8G:
46(14.5743) 96(20.5468)
3G足已,并发调到400測试:
180(23.7523)
调到5G:
183(24.1582)
3G够支撑400并发,xmx调到8G,看看性能是否下降。
179(22.70)
所以8G也够了。
调整thread count,原来是128,调到50:
177(11.6078)
调到30:
173(8.40206)
看来30个就够了,调整max queue到768(原来512):
167(8.62541)
调到1024:
169(8.69687)
所以还是维持原来的512.
一个经验,对于较少存活对象又要求高并发的。能够用ThreadLocal方式降低大对象的分配。假设没法消除(比方String之类的无法避免大量使用但又不能回首)一定要调大xmn(或new ratio)。