普通的性能調(diào)優(yōu)主要從四個(gè)方面入手
網(wǎng)絡(luò)，磁盤IO，內(nèi)存，CPU四個(gè)方面入手，下面案例就是從這四個(gè)角度來看。
?
我們的頁面每天PV在30W ，主要是分布在兩個(gè)主要頁面：個(gè)人主頁，展示主頁。假設(shè)每個(gè)頁面各自承擔(dān)50%的PV，假設(shè)訪問時(shí)間集中在白天8小時(shí)，平均下來每秒的請(qǐng)求數(shù)是 5.2個(gè)，考慮到高峰情況，那么我們就乘以系數(shù)20, 就當(dāng)100個(gè)處理，我們最大的一個(gè)請(qǐng)求會(huì)產(chǎn)生13個(gè)processor ,也就是說 最大產(chǎn)生的線程回事 13*100 = 1300。也就是說高峰時(shí)刻會(huì)有1300個(gè)線程需要被處理，我們將隊(duì)列設(shè)置為1000，對(duì)于高峰情況就拋棄，因?yàn)槿羰菫榱藵M足高峰情況的需要，就會(huì)使得部分請(qǐng)求處在隊(duì)列中，不能充分的利用CPU的資源。
?
在做壓力測(cè)試時(shí)候，自身應(yīng)用內(nèi)部做了小的多線程處理的框架，內(nèi)部采用的線程池是 SPRING的 ThreadPoolTaskExecutor 的類，通過自身的一個(gè)監(jiān)控框架我們發(fā)現(xiàn)，所有的線程單元執(zhí)行的很快，但是在最后組裝processor的時(shí)候，花費(fèi)了時(shí)間，在過程中觀察CPU的利用率并不是很高。
所以預(yù)估是在等待所有線程執(zhí)行完成時(shí)，也就是說有大量的processor在線程池的等待隊(duì)列中，為了驗(yàn)證是否由于該原因造成的，所以做如下測(cè)試：
?
因?yàn)榍懊嫣岬矫棵氲钠骄?qǐng)求是5.2 考慮到一般的情況，就設(shè)置為壓測(cè)的并發(fā)數(shù)為 3*5 = 15.
?
測(cè)試案例一：
?
15線程?
循環(huán)100次
線程池：
?corePoolSize ： CPU = 4?
?maxPoolSize ?： 2 * corePoolSize = 8?
?queueCapacity ： 1000?
?
壓測(cè)頁面： /xxx/22933?
?
---------------------------------------------- 這個(gè)是分割線 ----------------------------------------------
穩(wěn)定情況下的線程數(shù)：
[root@host_77-69 ~]# ps -eLf | grep java ?| wc -l?
229
主要是觀察，是否充分利用了CPU核數(shù)，達(dá)到我們預(yù)期的效果。現(xiàn)在的服務(wù)繼承很多框架或是模塊后，會(huì)啟動(dòng)很多你不知道的線程，在那跑著，時(shí)不時(shí)跳出來干擾你下，所以一定要等系統(tǒng)運(yùn)行穩(wěn)定后觀察這個(gè)數(shù)值。
---------------------------------------------- 這個(gè)是分割線 ----------------------------------------------
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
??
主要是關(guān)注 in ， cs 這兩個(gè)參數(shù)
in：每秒軟中斷次數(shù)
cs: 每秒上下文切換的次數(shù)
?
因?yàn)椴僮飨到y(tǒng)本身會(huì)有一些操作，在未壓測(cè)前的數(shù)值基本在 460 .800 左右。
---------------------------------------------- 這個(gè)是分割線 ----------------------------------------------
?
[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
??
關(guān)注soft 這個(gè)參數(shù) 這個(gè)代表當(dāng)前CPU在所有時(shí)間中，用于切換上下所化時(shí)間比,若是花費(fèi)的越多，代表當(dāng)前的線程切換過于頻繁，沒有充分利用CPU，建議減少線程數(shù)或是增加CPU。
user 、 nice、sys主要是觀察系統(tǒng)中是否存在大量計(jì)算，或是死循環(huán)的情況，來消耗大量的CPU。
這個(gè)命令是對(duì)于vmstat的補(bǔ)充，更直觀的觀察CPU的上下文切換及軟中斷情況。
?
---------------------------------------------- 下面是內(nèi)存的初始情況了 ----------------------------------------------
JVM自身的內(nèi)存情況：
?
[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次數(shù)基本不變，而且各個(gè)代內(nèi)存變化基本不大?
?
操作系統(tǒng)的內(nèi)存情況：
?
[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
??
數(shù)值也基本保持不變化
?
---------------------------------------------- 下面是磁盤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 ? ?每秒中讀取的塊數(shù)
Blk_wrtn/s ? ?每秒中寫的塊數(shù)
%iowait ? ? ? 當(dāng)前在等待磁盤IO的情況
?
---------------------------------------------- 說了這么多終于要開始了 ----------------------------------------------?
?
開始?jí)簻y(cè)后，得到下面的數(shù)據(jù)：
?
[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
??
在壓測(cè)的這個(gè)過程中，CPU大量上下文切換動(dòng)作明顯增加了很多。
?
[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
?
這個(gè)數(shù)據(jù)上看出其中一個(gè)CPU花費(fèi)在切換的時(shí)間比是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的線程數(shù)增加到了236，也就是說增加了7個(gè)，我們最初設(shè)置是4個(gè)，隊(duì)列1000 ，在隊(duì)列滿了后，增加了3個(gè)，也就是說，這種情況，擴(kuò)容到7個(gè)線程，就能滿足我們的壓測(cè)條件，那說明core為4，存在大量的隊(duì)列積壓情況，同時(shí)，上面的數(shù)據(jù)表明，用于上下文切換的比例也不是很高，如此我們就可以增加線程池的corePoolSize。那么下個(gè)案例就可以設(shè)置為8個(gè)試試看。
?
[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
?
?
這個(gè)是查看JVM的GC情況的，數(shù)據(jù)表明，壓測(cè)期間，ygc還是蠻頻繁，但是每次ygc后進(jìn)入old區(qū)的數(shù)據(jù)并不是很多，說明我們的應(yīng)用大部分是朝生夕死，并不會(huì)發(fā)生頻繁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
?
操作系統(tǒng)跟之心前相比，基本沒有發(fā)生任何的改變。
?
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
?
?
這個(gè)是當(dāng)前應(yīng)用對(duì)于磁盤的消耗情況，對(duì)比初始值，基本沒什么變化，可以看出我們這個(gè)應(yīng)用沒有磁盤IO的消耗，這說明本應(yīng)用并沒有大量的操作本地磁盤IO情況。
這個(gè)也不是導(dǎo)致我們系統(tǒng)慢的原因，也可以排除。
?
?
xxxModuleProcessor 33 最慢的processor是33毫秒
?
我們的processor最大的消耗是33毫秒，外部調(diào)用4.9ms ，但是最后看到的消耗時(shí)間是557ms，且上面的情況說明了，存在大量隊(duì)列積壓，我們的數(shù)據(jù)處理processor都在等待隊(duì)列了
?
下面是我們通過
Avg(ms):
第一次： 662.5 毫秒
第二次： 680 ? 毫秒
第三次： 690 ? 毫秒
?
通過上面的分析，平均響應(yīng)時(shí)間是：680ms,基本可以確定問題在于線程池corePoolSize過小,導(dǎo)致了一定的數(shù)據(jù)在隊(duì)列中積壓。
?
?
--------------------------------------------- ?這是一條偉大的分割線 ?---------------------------------------------
測(cè)試案例二：
?
改動(dòng)：增加一倍的corePoolSize
?
15線程?
循環(huán)100次
線程池：
?corePoolSize ；2 * CPU = ?8?
?maxPoolSize ?：2 * corePoolSize = 16?
?queueCapacity ： 1000?
?
壓測(cè)頁面： /member/22933?
?
--------------------------------------------- ?我又出現(xiàn)了 ?---------------------------------------------
?
再次啟動(dòng)穩(wěn)定后：
[root@host_77-69 ~]# for i in {1..10000};do ? ?ps -eLf | grep java ?| wc -l; echo "-------" ; sleep 2 ; done;
215
-------
215
-------
215
-------
?
java的線程數(shù)維持在215個(gè)，跟上面有點(diǎn)不同，當(dāng)然不管了，這個(gè)不是重點(diǎn)。
?
?
[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運(yùn)行都很正常?
?
?
[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
?
基本沒有軟中斷
?
壓測(cè)后得到如下數(shù)據(jù)：
[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
-------
這個(gè)java線程數(shù)的變化情況，從 214-- 221 -- 214。 初始化了8個(gè)，然后增加了7個(gè)，也就是說線程池中總共啟用了15個(gè)線程。
------------------------------------------------------ ?
?
[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
??
上面的數(shù)據(jù)表明，中斷占CPU的比例確大大增加了。單核中斷最高達(dá)到了7.25% 如此導(dǎo)致了什么結(jié)果呢?
?
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 性能反而下降了。平均響應(yīng)時(shí)間從662.5降到了731.7。
?
最慢的processor的消耗時(shí)間是： 187.9
?
期間也猜測(cè)可能是其中一個(gè)服務(wù)被我們壓壞了，就重啟了那個(gè)服務(wù)，再次壓測(cè)的結(jié)果是
Min(ms) Max(ms) Avg(ms) 95Line(ms) Std(ms) TPS
102.9 ?9188.9 762.5 ?1095.0 ? ?657.8 ?3.0
?
平均響應(yīng)時(shí)間是：750毫秒左右。
?
也就是說，基本可以確認(rèn)是由于我們?cè)黾恿?coreSize和maxSize導(dǎo)致性能變慢了。慢了近80毫秒。說明過多的CPU并不會(huì)加快我們的處理速度。
如此就有了下面的方案。
?
測(cè)試方案三：
corePoolSize : cpu數(shù)量 + 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的上下文切換還是很厲害。達(dá)到了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個(gè)，線程數(shù)確實(shí)增加到了10個(gè)，就是說10個(gè)線程對(duì)應(yīng)到4個(gè)CPU上，兩者的比例是1:2.25?
?
結(jié)果：
第一次壓測(cè)是：648毫秒
第二次壓測(cè)是：622毫秒
第三次壓測(cè)是：603毫秒
?
就取中間值吧：622毫秒?
?
性能想比較 core：8 max:16的話，有0.060毫秒的提升。說明一定cpu和進(jìn)程數(shù)保持在1:2.25的比例上，效率上還是有提高的，但是上下文切換的還是很厲害。
?
為了不讓它切換的這么厲害，就將max設(shè)置的小點(diǎn)吧。
?
測(cè)試方案四
線程：15?
循環(huán)：100次
corePoolSize : cpu數(shù)量 + 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
中斷時(shí)間確實(shí)從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
-------
線程池基本處于飽和狀態(tài)。
?
結(jié)果：
第一次壓測(cè)結(jié)果：629毫秒
第二次壓測(cè)結(jié)果：618毫秒
第三次壓測(cè)結(jié)果：586毫秒
?
這次CPU:線程數(shù)為1:2
相比較CPU和線程數(shù)1.2.25的結(jié)果有稍微的提升，因?yàn)镃PU中斷時(shí)間比下降了。
?
最終的結(jié)論，JVM的垃圾回收，本地磁盤IO，操作系統(tǒng)內(nèi)存都不會(huì)對(duì)本應(yīng)用產(chǎn)生影響，唯一的元素就是線程池大小的設(shè)置。目前測(cè)試出來的最佳策略是：
corePoolSize = cpu + 1
maxPoolSize = 2 *
cpu??
?
已有 0 人發(fā)表留言，猛擊->>這里<<-參與討論
ITeye推薦