普通的性能调优主要从四个方面入手
网络，磁盘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
压测页面： /xxx/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情况。
这个也不是导致我们系统慢的原因，也可以排除。
xxxModuleProcessor33 最慢的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
-------
219
-------
。。。。。。
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.4731.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.9762.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
-------
218
-------
线程池基本处于饱和状态。
结果：
第一次压测结果：629毫秒
第二次压测结果：618毫秒
第三次压测结果：586毫秒
这次CPU:线程数为1:2
相比较CPU和线程数1.2.25的结果有稍微的提升，因为CPU中断时间比下降了。
最终的结论，JVM的垃圾回收，本地磁盘IO，操作系统内存都不会对本应用产生影响，唯一的元素就是线程池大小的设置。目前测试出来的最佳策略是：
corePoolSize = cpu + 1
maxPoolSize = 2 * cpu
相关推荐
Oracle性能调优笔记
阿里巴巴Java性能调优华山版是一套系统性能调优教程，！通过这份笔记的学习，你将会有一个系统的调优头脑和策略！快了何止100％？需要的朋友可下载试试！ 众所周知性能调优可以使系统稳定，用户体验更佳，甚至在...
ORACLE DBA工作笔记 运维数据迁移与性能调优 清晰版 。。。
一.java内存结构 2 二 垃圾收集算法: 3 三 JVM参数 4 四 JVM的垃圾回收集器 7 五 常用参数设置 7
Oracle DBA性能调优学习笔记
linux性能调优学习笔记
辛星笔记的MySQL部分对于InnoDB的性能调优的笔记。
mysql调优笔记002
在开发过程中总结的ios性能调优技巧，其中有自己实际工程中的总结，也有从网络上的摘抄。
jvm 调优笔记-jvm
该资源为老师JVM调优讲解完整版课件,现在分享给大家,希望对与想进阶java的小伙伴带来帮助
mysql DBA工作笔记，怎么性能调优，运维相关：比如热点数据导出与加载的影响； RR与RC下Mysql 不同的加锁解锁方式等实战经验及理论知识
linux 参数调优
学习笔记——JVM性能调优之 jstat（csdn）————程序
Go语言学习（五） 高质量编程与性能调优实战_青训营笔记
马老师jvm实战调优课堂笔记，需要的小伙伴赶紧下载
最近几年进行ORACLE性能调优做的笔记,值得参考
本人精心整理的oracle调优笔记，包含很多调优技巧很调优工具
redis性能优化参考，主要是自己看redis开发与运维时做的读书笔记....拿出来分享...希望各位多多指教.
本人通过对oracle11g的性能优化指南 做了全面的翻译和整理工作，并将每一部分整理成文档，后续会陆续更新，希望对大家有帮助，尤其是不爱看英文原版的朋友特别有帮助。