上线性能调优笔记

普通的性能调优主要从四个方面入手
网络,磁盘IO,内存,CPU四个方面入手,下面案例就是从这四个角度来看。

我们的页面每天PV在30W ,主要是分布在两个主要页面:个人主页,展示主页。假设每个页面各自承担50%的PV,假设访问时间集中在白天8小时,平均下来每秒的请求数是 5.2个,考虑到高峰情况,那么我们就乘以系数20, 就当100个处理,我们最大的一个请求会产生13个processor ,也就是说 最大产生的线程回事 13*100 = 1300。也就是说高峰时刻会有1300个线程需要被处理,我们将队列设置为1000,对于高峰情况就抛弃,因为若是为了满足高峰情况的需要,就会使得部分请求处在队列中,不能充分的利用CPU的资源。

在做压力测试时候,自身应用内部做了小的多线程处理的框架,内部采用的线程池是 SPRING的 ThreadPoolTaskExecutor 的类,通过自身的一个监控框架我们发现,所有的线程单元执行的很快,但是在最后组装processor的时候,花费了时间,在过程中观察CPU的利用率并不是很高。
所以预估是在等待所有线程执行完成时,也就是说有大量的processor在线程池的等待队列中,为了验证是否由于该原因造成的,所以做如下测试:

因为前面提到每秒的平均请求是5.2 考虑到一般的情况,就设置为压测的并发数为 3*5 = 15.

测试案例一:

15线程
循环100次
线程池:
corePoolSize : CPU = 4
maxPoolSize : 2 * corePoolSize = 8
queueCapacity : 1000

压测页面: /member/22933

———————————————- 这个是分割线 ———————————————-

稳定情况下的线程数:
[root@host_77-69 ~]# ps -eLf | grep java | wc -l
229
主要是观察,是否充分利用了CPU核数,达到我们预期的效果。现在的服务继承很多框架或是模块后,会启动很多你不知道的线程,在那跑着,时不时跳出来干扰你下,所以一定要等系统运行稳定后观察这个数值。

———————————————- 这个是分割线 ———————————————-
CPU的一些信息:
[root@host_77-69 ~]# vmstat -ns 3
procs ———–memory———- —swap– —–io—- –system– —–cpu—–
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 2056 723528 392024 1330728 0 0 0 1 1 2 0 0 100 0 0
0 0 2056 723404 392024 1330728 0 0 0 0 467 806 0 0 100 0 0
0 0 2056 723404 392028 1330728 0 0 0 17 462 807 0 0 100 0 0
0 0 2056 723404 392028 1330728 0 0 0 0 457 814 0 0 100 0 0

主要是关注 in , cs 这两个参数
in:每秒软中断次数
cs: 每秒上下文切换的次数

因为操作系统本身会有一些操作,在未压测前的数值基本在 460 .800 左右。

———————————————- 这个是分割线 ———————————————-

[root@host_77-69 ~]# mpstat -P ALL 5
Linux 2.6.32-71.el6.x86_64 (host_77-69) 09/12/2012 _x86_64_ (4 CPU)

02:04:21 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
02:04:26 PM all 0.10 0.00 0.00 0.00 0.00 0.00 0.00 0.00 99.90
02:04:26 PM 0 0.20 0.00 0.00 0.00 0.00 0.00 0.00 0.00 99.80

关注soft 这个参数 这个代表当前CPU在所有时间中,用于切换上下所化时间比,若是花费的越多,代表当前的线程切换过于频繁,没有充分利用CPU,建议减少线程数或是增加CPU。
user 、 nice、sys主要是观察系统中是否存在大量计算,或是死循环的情况,来消耗大量的CPU。
这个命令是对于vmstat的补充,更直观的观察CPU的上下文切换及软中断情况。

———————————————- 下面是内存的初始情况了 ———————————————-

JVM自身的内存情况:
[root@host_77-69 ~]# jstat -gcutil `jps | grep -i main | awk ‘{print $1}’` 3000 1000
S0 S1 E O P YGC YGCT FGC FGCT GCT
0.00 0.00 90.91 13.56 60.25 26 0.877 2 0.802 1.679
0.00 0.00 91.17 13.56 60.25 26 0.877 2 0.802 1.679
0.00 0.00 91.27 13.56 60.25 26 0.877 2 0.802 1.679
0.00 0.00 91.28 13.56 60.25 26 0.877 2 0.802 1.679

fugcc次数基本不变,而且各个代内存变化基本不大

操作系统的内存情况:
[root@host_77-69 releases]# for i in {1..10};do free;sleep 3 ; done;
total used free shared buffers cached
Mem: 3925596 3223996 701600 0 392352 1330896
-/+ buffers/cache: 1500748 2424848
Swap: 4194296 2056 4192240
total used free shared buffers cached
Mem: 3925596 3223996 701600 0 392352 1330896
-/+ buffers/cache: 1500748 2424848
Swap: 4194296 2056 4192240
total used free shared buffers cached
Mem: 3925596 3223996 701600 0 392352 1330896
-/+ buffers/cache: 1500748 2424848
Swap: 4194296 2056 4192240

数值也基本保持不变化

———————————————- 下面是磁盘IO的初始情况了 ———————————————-
[root@host_77-69 ~]# for i in {1..10};do iostat ; sleep 3 ; done ;
Linux 2.6.32-71.el6.x86_64 (host_77-69) 09/12/2012 _x86_64_ (4 CPU)

avg-cpu: %user %nice %system %iowait %steal %idle
0.10 0.00 0.02 0.00 0.00 99.88

Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 0.31 0.33 5.93 1751462 31740872

Linux 2.6.32-71.el6.x86_64 (host_77-69) 09/12/2012 _x86_64_ (4 CPU)

avg-cpu: %user %nice %system %iowait %steal %idle
0.10 0.00 0.02 0.00 0.00 99.88

Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 0.31 0.33 5.93 1751462 31740960
主要观察
Blk_read/s 每秒中读取的块数
Blk_wrtn/s 每秒中写的块数
%iowait 当前在等待磁盘IO的情况
———————————————- 说了这么多终于要开始了 ———————————————-

开始压测后,得到下面的数据:

[root@host_77-69 ~]# vmstat -ns 3
procs ———–memory———- —swap– —–io—- –system– —–cpu—–
0 0 2056 698224 393212 1331344 0 0 0 3 536 867 0 0 100 0 0
3 0 2056 694796 393212 1332248 0 0 0 19 7170 7515 55 4 40 0 0
1 0 2056 694796 393212 1333132 0 0 0 4 7121 7627 50 5 45 0 0
4 0 2056 692936 393216 1334376 0 0 0 17 6478 8738 54 5 42 0 0
2 0 2056 691548 393232 1335620 0 0 0 25 6497 7663 48 4 48 0 0
5 0 2056 689936 393232 1337052 0 0 0 3 7597 7174 47 5 48 0 0
3 0 2056 688704 393232 1338496 0 0 0 12 7369 8774 49 5 45 0 0
3 0 2056 686348 393232 1341528 0 0 0 819 12298 16011 50 5 45 0 0
4 0 2056 684976 393236 1343020 0 0 0 12 6034 6951 48 4 48 0 0
3 0 2056 664268 393240 1344508 0 0 0 1 6731 9584 52 5 42 0 0
1 0 2056 659360 393240 1346284 0 0 0 12 7797 8431 54 5 41 0 0
2 0 2056 657624 393240 1347564 0 0 0 2684 6908 7656 50 5 45 0 0

在压测的这个过程中,CPU大量上下文切换动作明显增加了很多。

[root@host_77-69 ~]# mpstat -P ALL 5
04:01:32 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
04:01:37 PM all 0.15 0.00 0.10 0.00 0.00 0.05 0.00 0.00 99.70
04:01:37 PM 0 0.20 0.00 0.00 0.00 0.00 0.20 0.00 0.00 99.60
04:01:37 PM 1 0.20 0.00 0.00 0.00 0.00 0.00 0.00 0.00 99.80
04:01:37 PM 2 0.20 0.00 0.00 0.00 0.00 0.00 0.00 0.00 99.80
04:01:37 PM 3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
这个数据上看出其中一个CPU花费在切换的时间比是0.2%,也不是很高。
[root@host_77-69 ~]# ps -eLf | grep java | wc -l
229
[root@host_77-69 ~]# ps -eLf | grep java | wc -l
236
[root@host_77-69 ~]# ps -eLf | grep java | wc -l
236
[root@host_77-69 ~]# ps -eLf | grep java | wc -l
235
[root@host_77-69 ~]# ps -eLf | grep java | wc -l
229
[root@host_77-69 ~]# ps -eLf | grep java | wc -l
229

java的线程数增加到了236,也就是说增加了7个,我们最初设置是4个,队列1000 ,在队列满了后,增加了3个,也就是说,这种情况,扩容到7个线程,就能满足我们的压测条件,那说明core为4,存在大量的队列积压情况,同时,上面的数据表明,用于上下文切换的比例也不是很高,如此我们就可以增加线程池的corePoolSize。那么下个案例就可以设置为8个试试看。

[root@host_77-69 ~]# jstat -gcutil `jps | grep -i main | awk ‘{print $1}’` 3000 1000
S0 S1 E O P YGC YGCT FGC FGCT GCT
0.00 27.46 76.94 19.37 60.86 31 1.139 3 1.497 2.636
0.00 23.34 85.64 19.37 60.90 33 1.150 3 1.497 2.647
0.00 36.14 38.44 19.37 60.91 35 1.167 3 1.497 2.665
0.00 63.19 37.87 19.37 60.92 37 1.191 3 1.497 2.688
59.29 0.00 1.61 19.48 60.92 40 1.226 3 1.497 2.723
0.00 50.63 58.22 19.50 60.93 41 1.236 3 1.497 2.733
0.00 51.09 70.36 19.58 60.94 43 1.265 3 1.497 2.762
44.05 0.00 2.09 19.67 60.95 46 1.298 3 1.497 2.795
0.00 83.74 75.70 19.68 60.96 47 1.316 3 1.497 2.813
0.00 89.57 77.32 20.21 60.96 49 1.350 3 1.497 2.847
46.02 0.00 36.83 22.12 60.97 52 1.399 3 1.497 2.896
36.69 0.00 37.78 22.12 60.98 54 1.417 3 1.497 2.914
59.51 0.00 23.47 22.12 61.00 56 1.435 3 1.497 2.932
64.53 0.00 36.51 22.29 61.03 58 1.461 3 1.497 2.959
73.19 0.00 78.00 23.01 61.05 60 1.497 3 1.497 2.995
54.24 0.00 36.10 23.01 61.06 62 1.521 3 1.497 3.018
79.36 0.00 82.65 23.01 61.08 64 1.547 3 1.497 3.044
0.00 68.75 48.34 26.61 61.10 67 1.606 3 1.497 3.103
29.33 0.00 93.75 26.61 61.12 68 1.613 3 1.497 3.110
0.00 45.32 23.68 26.61 61.12 71 1.640 3 1.497 3.138
34.93 0.00 19.75 29.84 61.13 74 1.697 3 1.497 3.194
22.59 0.00 27.47 29.84 61.14 76 1.711 3 1.497 3.208
54.40 0.00 74.16 30.45 61.15 78 1.734 3 1.497 3.231
25.23 0.00 77.50 30.45 61.15 80 1.747 3 1.497 3.245
25.23 0.00 98.39 30.45 61.15 80 1.747 3 1.497 3.245
25.23 0.00 99.94 30.45 61.15 80 1.747 3 1.497 3.245
0.00 14.32 1.42 30.45 61.15 81 1.752 3 1.497 3.250
0.00 14.32 2.15 30.45 61.15 81 1.752 3 1.497 3.250
0.00 14.32 2.27 30.45 61.15 81 1.752 3 1.497 3.250
0.00 14.32 2.48 30.45 61.15 81 1.752 3 1.497 3.250

这个是查看JVM的GC情况的,数据表明,压测期间,ygc还是蛮频繁,但是每次ygc后进入old区的数据并不是很多,说明我们的应用大部分是朝生夕死,并不会发生频繁fgc的情况,之后就不用把重心放在JVM的GC上。
[root@host_77-69 releases]# for i in {1..10};do free;sleep 3 ; done;
total used free shared buffers cached
Mem: 3925596 3370968 554628 0 395584 1369572
-/+ buffers/cache: 1605812 2319784
Swap: 4194296 2056 4192240
操作系统跟之心前相比,基本没有发生任何的改变。
avg-cpu: %user %nice %system %iowait %steal %idle
0.10 0.00 0.02 0.00 0.00 99.88

Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 0.31 0.33 5.95 1751462 31823032

Linux 2.6.32-71.el6.x86_64 (host_77-69) 09/12/2012 _x86_64_ (4 CPU)

avg-cpu: %user %nice %system %iowait %steal %idle
0.10 0.00 0.02 0.00 0.00 99.88

Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 0.31 0.33 5.95 1751462 31823032

这个是当前应用对于磁盘的消耗情况,对比初始值,基本没什么变化,可以看出我们这个应用没有磁盘IO的消耗,这说明本应用并没有大量的操作本地磁盘IO情况。
这个也不是导致我们系统慢的原因,也可以排除。
com.dianping.userweb.service.processor.VisitorModuleProcessor 33 最慢的processor是33毫秒

我们的processor最大的消耗是33毫秒,外部调用4.9ms ,但是最后看到的消耗时间是557ms,且上面的情况说明了,存在大量队列积压,我们的数据处理processor都在等待队列了

下面是我们通过
Avg(ms):
第一次: 662.5 毫秒
第二次: 680 毫秒
第三次: 690 毫秒

通过上面的分析,平均响应时间是:680ms,基本可以确定问题在于线程池corePoolSize过小,导致了一定的数据在队列中积压。
——————————————— 这是一条伟大的分割线 ———————————————
测试案例二:

改动:增加一倍的corePoolSize

15线程
循环100次
线程池:
corePoolSize ;2 * CPU = 8
maxPoolSize :2 * corePoolSize = 16
queueCapacity : 1000

压测页面: /member/22933

——————————————— 我又出现了 ———————————————

再次启动稳定后:
[root@host_77-69 ~]# for i in {1..10000};do ps -eLf | grep java | wc -l; echo “——-” ; sleep 2 ; done;
215
——-
215
——-
215
——-

java的线程数维持在215个,跟上面有点不同,当然不管了,这个不是重点。

[root@host_77-69 ~]# vmstat -ns 3
procs ———–memory———- —swap– —–io—- –system– —–cpu—–
0 0 2056 933420 395768 1341376 0 0 0 8 579 875 0 0 100 0 0
0 0 2056 933420 395768 1341376 0 0 0 3 579 860 0 0 100 0 0
0 0 2056 933420 395776 1341372 0 0 0 9 568 867 0 0 100 0 0

初始情况CPU运行都很正常

[root@host_77-69 ~]# mpstat -P ALL 5
Linux 2.6.32-71.el6.x86_64 (host_77-69) 09/12/2012 _x86_64_ (4 CPU)

05:43:34 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
05:43:39 PM all 0.40 0.00 0.10 0.00 0.00 0.00 0.00 0.00 99.50
05:43:39 PM 0 0.80 0.00 0.20 0.00 0.00 0.00 0.00 0.00 99.00

基本没有软中断

压测后得到如下数据:
[root@host_77-69 ~]# for i in {1..10000};do ps -eLf | grep java | wc -l; echo “——-” ; sleep 2 ; done;
214
——-
214
——-
214
——-
217
——-
219
——-
219
——-
。。。。。。
221
——-
221
——-
219
——-
。。。。。。
218
——-
218
——-
218
——-
214
——-

这个java线程数的变化情况,从 214– 221 — 214。 初始化了8个,然后增加了7个,也就是说线程池中总共启用了15个线程。

——————————————————
[root@host_77-69 ~]# mpstat -P ALL 5
05:59:00 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
05:59:05 PM all 51.46 0.00 4.58 0.00 0.29 2.00 0.00 0.00 41.67
05:59:05 PM 0 50.98 0.00 4.71 0.00 0.98 7.25 0.00 0.00 36.08
05:59:05 PM 1 51.07 0.00 4.29 0.00 0.00 0.39 0.00 0.00 44.25
05:59:05 PM 2 50.49 0.00 4.87 0.00 0.00 0.19 0.00 0.00 44.44
05:59:05 PM 3 53.29 0.00 4.46 0.00 0.00 0.19 0.00 0.00 42.05

05:59:05 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
05:59:10 PM all 49.56 0.00 4.25 0.00 0.29 2.00 0.00 0.00 43.89
05:59:10 PM 0 46.56 0.00 3.73 0.00 1.18 7.07 0.00 0.00 41.45
05:59:10 PM 1 58.12 0.00 4.31 0.00 0.00 0.39 0.00 0.00 37.18
05:59:10 PM 2 45.72 0.00 4.67 0.00 0.00 0.39 0.00 0.00 49.22
05:59:10 PM 3 47.95 0.00 4.29 0.00 0.00 0.39 0.00 0.00 47.37

05:59:10 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
05:59:15 PM all 50.54 0.00 4.19 0.00 0.29 1.75 0.00 0.00 43.23
05:59:15 PM 0 55.36 0.00 3.70 0.00 1.17 5.85 0.00 0.00 33.92
05:59:15 PM 1 53.62 0.00 4.70 0.00 0.00 0.59 0.00 0.00 41.10
05:59:15 PM 2 46.98 0.00 4.29 0.00 0.00 0.19 0.00 0.00 48.54
05:59:15 PM 3 46.21 0.00 4.27 0.00 0.00 0.19 0.00 0.00 49.32

05:59:15 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
05:59:20 PM all 52.78 0.00 4.48 0.05 0.39 2.14 0.00 0.00 40.17
05:59:20 PM 0 52.17 0.00 3.94 0.00 1.57 7.68 0.00 0.00 34.65
05:59:20 PM 1 52.35 0.00 4.90 0.00 0.00 0.39 0.00 0.00 42.35
05:59:20 PM 2 57.09 0.00 4.85 0.00 0.00 0.19 0.00 0.00 37.86
05:59:20 PM 3 49.42 0.00 4.23 0.00 0.00 0.38 0.00 0.00 45.96

05:59:20 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
05:59:25 PM all 46.90 0.00 3.85 0.00 0.34 1.76 0.00 0.00 47.15
05:59:25 PM 0 48.34 0.00 3.70 0.00 1.56 6.43 0.00 0.00 39.96
05:59:25 PM 1 43.30 0.00 4.47 0.00 0.00 0.39 0.00 0.00 51.84
05:59:25 PM 2 50.59 0.00 3.52 0.00 0.00 0.39 0.00 0.00 45.51
05:59:25 PM 3 45.14 0.00 3.70 0.00 0.00 0.19 0.00 0.00 50.97

上面的数据表明,中断占CPU的比例确大大增加了。单核中断最高达到了7.25% 如此导致了什么结果呢?

Min(ms) Max(ms) Avg(ms) 95Line(ms) Std(ms) TPS
161.2 8877.4 731.7 1000.0 65.3 1.2

想比较corePoolSize:4 max:8 性能反而下降了。平均响应时间从662.5降到了731.7。

最慢的processor的消耗时间是: 187.9

期间也猜测可能是其中一个服务被我们压坏了,就重启了那个服务,再次压测的结果是
Min(ms) Max(ms) Avg(ms) 95Line(ms) Std(ms) TPS
102.9 9188.9 762.5 1095.0 657.8 3.0

平均响应时间是:750毫秒左右。

也就是说,基本可以确认是由于我们增加了 coreSize和maxSize导致性能变慢了。慢了近80毫秒。说明过多的CPU并不会加快我们的处理速度。
如此就有了下面的方案。

测试方案三:
corePoolSize : cpu数量 + 1 = 5
maxPoolSzie : 2 * corePoolSize  = 10

我们看下具体情况吧:

[root@host_77-69 ~]# mpstat -P ALL 5
06:57:36 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
06:57:41 PM all 58.27 0.00 5.38 0.00 0.49 2.30 0.00 0.00 33.56
06:57:41 PM 0 61.66 0.00 4.74 0.00 1.98 8.10 0.00 0.00 23.52
06:57:41 PM 1 55.75 0.00 5.65 0.00 0.00 0.58 0.00 0.00 38.01
06:57:41 PM 2 57.81 0.00 5.47 0.00 0.00 0.20 0.00 0.00 36.52

CPU的上下文切换还是很厉害。达到了8.10%
[root@host_77-69 ~]# for i in {1..10000};do ps -eLf | grep java | wc -l; echo “——-” ; sleep 2 ; done;
214
——-
214
——-
219
——-
——-
219
——-
217
——-
215
——-
214

214–219
原来线程池core是5,我们最大是10个,线程数确实增加到了10个,就是说10个线程对应到4个CPU上,两者的比例是1:2.25
结果:
第一次压测是:648毫秒
第二次压测是:622毫秒
第三次压测是:603毫秒

就取中间值吧:622毫秒
性能想比较 core:8 max:16的话,有0.060毫秒的提升。说明一定cpu和进程数保持在1:2.25的比例上,效率上还是有提高的,但是上下文切换的还是很厉害。

为了不让它切换的这么厉害,就将max设置的小点吧。

测试方案四
线程:15
循环:100次
corePoolSize : cpu数量 + 1 = 5
maxPoolSzie : 2 * cpu = 8
08:13:13 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
08:13:18 PM all 52.45 0.00 4.60 0.00 0.10 1.27 0.00 0.00 41.58
08:13:18 PM 0 60.00 0.00 3.96 0.00 0.59 3.96 0.00 0.00 31.49
08:13:18 PM 1 50.29 0.00 5.48 0.00 0.00 0.20 0.00 0.00 44.03
08:13:18 PM 2 50.78 0.00 4.86 0.00 0.00 0.58 0.00 0.00 43.77
08:13:18 PM 3 48.83 0.00 4.28 0.00 0.00 0.19 0.00 0.00 46.69

08:13:18 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
08:13:23 PM all 50.05 0.00 4.29 0.00 0.10 1.22 0.00 0.00 44.34
08:13:23 PM 0 57.54 0.00 4.56 0.00 0.20 3.97 0.00 0.00 33.73
08:13:23 PM 1 49.81 0.00 4.28 0.00 0.00 0.39 0.00 0.00 45.53
08:13:23 PM 2 48.16 0.00 3.88 0.00 0.00 0.39 0.00 0.00 47.57
08:13:23 PM 3 45.07 0.00 4.45 0.00 0.00 0.19 0.00 0.00 50.29

08:13:23 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
08:13:28 PM all 51.34 0.00 4.69 0.00 0.10 1.27 0.00 0.00 42.60
08:13:28 PM 0 60.08 0.00 4.15 0.00 0.40 3.95 0.00 0.00 31.42
08:13:28 PM 1 47.75 0.00 6.07 0.00 0.00 0.39 0.00 0.00 45.79
08:13:28 PM 2 47.48 0.00 4.26 0.00 0.00 0.39 0.00 0.00 47.87
08:13:28 PM 3 50.19 0.00 4.28 0.00 0.00 0.39 0.00 0.00 45.14

中断时间确实从7%下降到了4%左右。
[root@host_77-69 ~]# for i in {1..10000};do ps -eLf | grep java | wc -l; echo “——-” ; sleep 2 ; done;
215
——-
217
——-
217
——-
219
——-
219
——-
219
——-
219
——-
219
——-
218
——-

线程池基本处于饱和状态。

结果:
第一次压测结果:629毫秒
第二次压测结果:618毫秒
第三次压测结果:586毫秒

这次CPU:线程数为1:2
相比较CPU和线程数1.2.25的结果有稍微的提升,因为CPU中断时间比下降了。

最终的结论,JVM的垃圾回收,本地磁盘IO,操作系统内存都不会对本应用产生影响,唯一的元素就是线程池大小的设置。目前测试出来的最佳策略是:
corePoolSize = cpu + 1
maxPoolSize = 2 * cpu

一个说的更全面的文章:
http://blog.fulin.org/2012/06/perf_tunning.html

作者: inter12

在这苦短的人生中,追求点自己的简单快乐

发表评论

电子邮件地址不会被公开。 必填项已用*标注