MCache压力测试-3

04.10.2012,Workdiary,byjarit.

经过调整几个参数，GC的表现越来越理想了。
实践发现，对象的大小对TPS影响明显，压128~500k之间随机大小时TPS2w，压128~10k之间随机时TPS达到40+w（后面补个对比图）。
现在稳定的数据是：
测试参数：
curl“localhost:8088/perf.do?method=mcache×=90000000000&min=128&max=10240&key=1000000&expire=3000&threads=5&t=2000″

TPS情况：
get/s:478087
hitrate:97.21%
put/s:13328

CPU20%Load1.5
CMSGC50分钟一次

配置如下：
-Xmx2g
-Xms2g
-Xmn1g
-verbose:jni
-verbose:gc
-Xloggc:./log/gc.log
-XX:SurvivorRatio=8
-XX:MaxTenuringThreshold=15
-XX:+PrintGCDateStamps
-XX:+PrintGCTimeStamps
-XX:+PrintGCDetails
-XX:+PrintTenuringDistribution
-XX:+PrintCommandLineFlags
-XX:+PrintTenuringDistribution
-XX:+HeapDumpOnOutOfMemoryError
-XX:-OmitStackTraceInFastThrow
-XX:+DisableExplicitGC
-XX:+UseConcMarkSweepGC
-XX:ParallelCMSThreads=4
-XX:+CMSClassUnloadingEnabled
-XX:+UseCMSCompactAtFullCollection
-XX:CMSInitiatingOccupancyFraction=80
-XX:MaxDirectMemorySize=2g

同时，发现了设计上的缺陷：
之前的测试，都是在命中率97%左右的情况，对象数增长被限制，OLD大概100M左右恒定回收不掉，但是不影响。
通过扩大key的随机范围(足够大)，将命中率降到0.5%，意味着，操作是以put为主，这样，很快OLD区就占满了，然后开始FGC,压测指标直速下降，并且，FGC并不能释放内存。
测试数据：
curl“localhost:8088/perf.do?method=mcache×=90000000000&min=51200&max=51200&key=10000000000&expire=3000&threads=5&t=1000″
运行情况：
12/04/1015:08:55hit:0.00%gps:82092put/s:82085in:3.93gout:200.00k
12/04/1015:09:31hit:0.19%gps:80922pps:80771in:3.86gout:7.42m
12/04/1015:10:41hit:0.54%gps:64848pps:64495in:3.11gout:17.38m
12/04/1015:10:42hit:0.53%gps:57139pps:56838in:3.12gout:16.94m
12/04/1015:10:52hit:0.51%gps:5860pps:5830in:2.53gout:13.23m
12/04/1015:11:00hit:0.40%gps:1624pps:1618in:644.29mout:2.59m
12/04/1015:13:44hit:0.49%gps:1998pps:1988in:821.09mout:4.05m
12/04/1015:14:33hit:0.55%gps:239pps:238in:573.24mout:3.17m
12/04/1015:17:06hit:0.30%gps:2309pps:2302in:670.36mout:2.05m
上边的数据跟JVMGC数据一致，OLD内存一直涨到1G，开始FGC，并且释放不掉

解决办法：
中间对象长驻内存不能释放，就是内存泄露了。MCache同要有一种清理过期的对象并释放，让GC有机会回收。
假设过期对象能及时回收，堆的大小至少要大于过期时间内活跃对象总大小。关键点还是会回到堆内存大小、单个中间对象大小、过期时长几个因素上来了。