普通的性能調優主要從四個方面入手
網絡，磁盤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情況。
這個也不是導致我們系統慢的原因，也可以排除。
?
?
xxxModuleProcessor 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
-------
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.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
-------
218
-------
線程池基本處于飽和狀態。
?
結果：
第一次壓測結果：629毫秒
第二次壓測結果：618毫秒
第三次壓測結果：586毫秒
?
這次CPU:線程數為1:2
相比較CPU和線程數1.2.25的結果有稍微的提升，因為CPU中斷時間比下降了。
?
最終的結論，JVM的垃圾回收，本地磁盤IO，操作系統內存都不會對本應用產生影響，唯一的元素就是線程池大小的設置。目前測試出來的最佳策略是：
corePoolSize = cpu + 1
maxPoolSize = 2 *
cpu??
?
已有 0 人發表留言，猛擊->>這里<<-參與討論
ITeye推薦