2011-05-25 144 views
2

我們正在Linux機箱中測試運行在IBM門戶服務器上的應用程序,但發現即使在測試之後,vmstat的「空閒」值也在穩步下降。通過查看頂部,「VIRT」值也穩步增加。通過監控Java應用程序堆的使用情況,從未達到初始堆大小(1.5G),並且使用率從6xxm到測試結束期間緩慢且穩定地上升(在測試期內略有上升/下降)。當測試剛剛結束時,它大幅下降到大約6XXm。我的問題是: 1.結果正常嗎? 2.應用程序堆使用行爲是否正常? 3. vmstat的「free」值是否穩定下降,top的「VIRT」值在測試後沒有下降,穩定增加是正常的?加載測試內存問題

以下是頂部和vmstat輸出:

PID USER  PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND    
14157 user01 17 0 2508m 1.2g 47m S 16.0 23.3 11:38.94 java    
14157 user01 17 0 2508m 1.2g 47m S 16.9 23.3 11:49.08 java    
14157 user01 17 0 2508m 1.2g 47m S 15.8 23.4 11:58.58 java    
14157 user01 17 0 2509m 1.2g 47m S 13.0 23.5 12:06.36 java    
14157 user01 17 0 2509m 1.2g 47m S 17.6 23.5 12:16.92 java    
14157 user01 17 0 2509m 1.2g 47m S 16.9 23.6 12:27.09 java    
14157 user01 17 0 2510m 1.2g 47m S 16.1 23.6 12:36.73 java    
14157 user01 17 0 2510m 1.2g 47m S 14.5 23.7 12:45.43 java    
... 
14157 user01 17 0 2514m 1.2g 47m S 15.9 24.6 15:20.18 java    
14157 user01 17 0 2514m 1.2g 47m S 16.2 24.6 15:29.88 java    
14157 user01 17 0 2514m 1.2g 47m S 16.1 24.7 15:39.56 java    
14157 user01 17 0 2515m 1.2g 47m S 19.5 24.7 15:51.28 java    
14157 user01 17 0 2516m 1.2g 47m S 11.4 24.8 15:58.11 java    
14157 user01 17 0 2515m 1.2g 47m S 14.7 24.8 16:06.91 java    
14157 user01 17 0 2515m 1.2g 47m S 16.0 24.9 16:16.51 java    
14157 user01 17 0 2515m 1.2g 47m S 16.1 24.9 16:26.15 java    
14157 user01 17 0 2515m 1.2g 47m S 14.7 25.0 16:34.96 java    
14157 user01 17 0 2516m 1.2g 47m S 11.8 25.0 16:42.03 java    
... 
14157 user01 17 0 2517m 1.3g 47m S 13.1 25.6 18:18.04 java    
14157 user01 17 0 2517m 1.3g 47m S 17.8 25.6 18:28.75 java    
14157 user01 17 0 2516m 1.3g 47m S 15.2 25.7 18:37.85 java    
14157 user01 17 0 2517m 1.3g 47m S 13.5 25.7 18:45.93 java    
14157 user01 17 0 2516m 1.3g 47m S 14.6 25.8 18:54.70 java    
14157 user01 17 0 2517m 1.3g 47m S 14.6 25.8 19:03.47 java    
14157 user01 17 0 2517m 1.3g 47m S 15.3 25.9 19:12.67 java    
14157 user01 17 0 2517m 1.3g 47m S 16.6 25.9 19:22.64 java    
14157 user01 17 0 2517m 1.3g 47m S 15.0 26.0 19:31.65 java    
14157 user01 17 0 2517m 1.3g 47m S 12.4 26.0 19:39.09 java    
... 
14157 user01 17 0 2530m 1.4g 47m S 0.0 27.5 23:23.91 java    


procs -----------memory---------- ---swap-- -----io---- -system-- -----cpu------ 
r b swpd free buff cache si so bi bo in cs us sy id wa st 
1 0 2004 702352 571508 1928436 0 0  0 54 287 413 1 1 98 0 0 
0 0 2004 702368 571528 1928416 0 0  0 12 280 379 0 0 100 0 0 
... 
24 0 2004 673988 572504 1948000 0 0  0 440 760 751 16 6 78 0 0 
0 0 2004 671352 572540 1951048 0 0  0 477 1180 830 19 7 74 0 0 
0 0 2004 674756 572572 1946904 0 0  0 380 604 650 13 3 84 0 0 
1 0 2004 694208 572612 1928360 0 0  0 222 518 599 7 2 91 0 0 
16 0 2004 692068 572640 1929360 0 0  0 539 1075 850 24 7 69 0 0 
0 0 2004 689036 572680 1931376 0 0  0 292 978 781 14 6 81 0 0 
... 
0 0 2004 530432 579120 2007176 0 0  0 453 511 712 18 4 78 0 0 
0 0 2004 528440 579152 2008172 0 0  0 200 436 652 10 2 87 0 0 
0 0 2004 524352 579192 2010188 0 0  0 401 514 779 17 6 76 0 0 
0 0 2004 524964 578208 2012200 0 0  0 514 475 696 15 3 82 0 0 
0 0 2004 522484 578260 2013176 0 0  0 416 488 699 15 3 82 0 0 
2 0 2004 521264 578300 2015192 0 0  0 368 501 728 14 5 80 0 0 
0 0 2004 518400 578340 2016180 0 0  0 404 452 647 14 3 84 0 0 
25 0 2004 517064 578368 2018208 0 0  0 414 497 752 15 3 82 0 0 
... 
0 0 2004 499312 578820 2029064 0 0  0 351 459 660 13 3 84 0 0 
0 0 2004 496228 578872 2031068 0 0  0 260 473 701 15 5 80 0 0 
0 0 2004 501360 578912 2026916 0 0  0 500 398 622 9 3 88 0 0 
1 0 2004 499260 578948 2027908 0 0  0 262 436 638 13 2 85 0 0 
1 0 2004 497964 578984 2028900 0 0  0 276 452 628 15 3 82 0 0 
0 0 2004 497492 579024 2029888 0 0  0 200 384 548 7 2 91 0 0 
0 0 2004 496620 579044 2030896 0 0  0 172 393 586 9 2 89 0 0 
... 
1 0 2004 357876 566000 2104592 0 0  0 374 510 736 18 6 76 0 0 
23 0 2004 358544 566032 2105588 0 0  0 362 456 644 12 3 85 0 0 
0 0 2004 376332 566084 2087032 0 0  0 353 441 614 13 3 84 0 0 
0 0 2004 375888 566120 2088024 0 0  0 220 411 620 10 2 88 0 0 
0 0 2004 375280 566156 2087988 0 0  0 224 408 586 7 2 91 0 0 
16 0 2004 373092 566188 2090012 0 0  0 233 494 723 12 3 85 0 0 
2 0 2004 369564 566236 2090992 0 0  0 455 475 714 14 5 80 1 0 
... 
r b swpd free buff cache si so bi bo in cs us sy id wa st 
1 0 2004 235156 572776 2155384 0 0  0  8 282 396 0 0 100 0 0 
0 0 2004 235132 572796 2155364 0 0  0 24 291 435 0 0 100 0 0 
1 0 2004 234780 572828 2155332 0 0  0 101 292 474 1 5 94 0 0 
0 0 2004 234804 572844 2155316 0 0  0 45 288 451 0 1 99 0 0 
0 0 2004 234852 572856 2155304 0 0  0 12 283 409 0 0 100 0 0 

堆用法: heap

回答

1

,你所看到的最可能的原因是,-Xms和-Xmx值在JAVA_OPTS不同。這裏發生的情況是,操作系統在JVM需要時分配內存。在啓動時將所有需要的堆分配給JVM永遠不是壞習慣。將2個值設置爲其上限。通過設置這兩個值相等,JVM從不需要從操作系統請求內存,並且可以自由地在自己的內存空間內完成所需的工作。

看到您所看到的行爲並不罕見,JVM將繼續從操作系統請求更多內存,直到達到上限(-Xmx)。如果您不熟悉調整堆大小或調整JVM的其他技巧,請參閱this guide

另一方面,top和vmstat只會向您展示如何瞭解JVM的內存情況。你所看到的是操作系統分配給它的東西。您將需要使用其他工具(例如jmapjvisualvm)來查看JVM內部的內存如何響應。這些工具將成爲您的應用的更好的基準標記。他們將向你展示的是新舊世代,垃圾收集和其他非常重要的數據。

+0

謝謝。我剛剛放了一張圖表,顯示Java應用程序堆大小和使用情況 – blue 2011-05-25 16:48:50

+0

也記住你的JAVA_OPTS? – Sean 2011-05-25 17:01:42

+0

我可以根據圖表看到工作進行的時間(5:04之前)以及停止時間(5:04之後)。那裏一切看起來不錯。你分配的堆是不斷變化的,所以如果你關心JVM改變堆大小,我建議你調整一些啓動參數。 – Sean 2011-05-25 17:04:29