Sun OS下,一個(gè)系統(tǒng)sys很高的問題

linux_gao

請教大家一個(gè)sys較高的問題,(OS是 SunOS 5.9)一直沒有得到很好的解決:

load averages: 19.26,  9.54,  4.03                                                                                         19:02:04
253 processes: 249 sleeping, 1 running, 3 on cpu
CPU states: 13.2% idle, 10.7% user, 73.4% kernel,  2.7% iowait,  0.0% swap
Memory: 32G real, 23G free, 2189M swap in use, 38G swap free
   PID USERNAME LWP PRI NICE  SIZE   RES STATE    TIME    CPU COMMAND
18600 appadm     1   0    0   33M   23M sleep    0:33  5.20% fxfdr
17409 appadm     1  60    0  135M   51M run     20:43  4.25% fxfdr
18749 appadm     1  60    0  127M   49M sleep    0:32  4.17% fxfdr
18498 appadm     1  60    0   80M   23M sleep    0:30  3.88% fxfdr
15848 appadm     1  43    0   29M   21M sleep    0:03  1.02% lh_correlate

應(yīng)用其實(shí)占的資源也不是很多,我弄不明白的就是為什么kernel用掉了這么多資源,也不清楚他在干什么,大家能不能給提供一些思路,或者一些可能存在問題的地方,謝謝大家

linux_gao

連個(gè)思路也沒有嗎?

race

ps -eo pid,pcpu,args |sort +1n查一下是哪個(gè)進(jìn)程

aping2005

一個(gè)字，查.
十有八九是由于某個(gè)異常進(jìn)程導(dǎo)致，一個(gè)個(gè)逐步的停掉看。

Snowict

首先查內(nèi)存的占用情況。一般系統(tǒng)使用過多的CPU資源，由于大量的調(diào)度，很多的時(shí)候是由于內(nèi)存資源。
從信息中看IO調(diào)度不多�？纯磒age 調(diào)度。

codefan

怪哉，內(nèi)存這么多free還用swap!!!
估計(jì)，肯定有程序在代碼中強(qiáng)行使用swap,并且頻繁調(diào)用內(nèi)存和swap同步。
用vmstat 看看i/o情況。

linux_gao

我用vmstat執(zhí)行后,,麻煩大家?guī)兔σ黄鹂匆幌?謝謝了.
我們知道是這個(gè)進(jìn)程的問題,只是想定位一下產(chǎn)生這種情況的原因,這樣才好處理一些,程序不是國內(nèi)開發(fā)的,所以我們也不能用一些代碼調(diào)試工具之類的,郁悶啊.

[/export/home/appadm]$ vmstat
kthr      memory            page            disk          faults      cpu
r b w   swap  free  re  mf pi po fr de sr m1 m2 m3 m4   in   sy   cs us sy id
0 0 0 40669952 25425896 146 657 53 117 117 0 0 0 0 0 0 286 1554  959  2  2 95

====進(jìn)程開啟后,load average 大于10
[/export/home/appadm]$ vmstat

kthr      memory             page                       disk         faults        cpu
r b w   swap     free     re   mf   pi   po    fr  de sr m1 m2 m3m4 in  sy  cs  us sy id
12 0 0 39158816 23903272 1630 3003  378  8998  8998  0 0 0 0 0 0 4126 21245 5253 15 38 47
15 1 0 39164880 23889824 3068 7999  370  16056 16056 0 0 0 0 0 0 5780 33697 6816 22 45 32
14 1 0 39161816 23900688 3517 7331  252  9357  9357  0 0 0 0 0 0 4640 28736 6007 22 68 9
2 1 0  39154008 23871224 2594 6206  56   15917 15917 0 0 0 0 0 0 4170 19326 4779 7  34 59
9 3 0  39161440 23891448 1324 986   11   2758  2758  0 0 0 0 0 0 2826 12253 3892 9  32 59
3 1 0  39161912 23760816 3983 9454  68   3081  3081  0 0 0 0 0 0 4240 30652 7164 17 49 34
0 2 0  39139768 23854680 238  1824  70   23842 23842 0 0 0 0 0 0 4173 13547 3489 9  10 81
30 4 0 39161992 23884040 1412 2635  340  1404  1404  0 0 0 0 0 0 4663 20573 4789 16 70 13
0 2 0  39162728 23759376 3259 8470  315  2277  2277  0 0 0 0 0 0 2853 22795 4645 13 24 63
9 2 0  39161680 23795960 237  1821  166  9308  9308  0 0 0 0 0 0 2985 4965  1728 7  26 68
0 3 0  39151672 23851072 54   473    0   12185 12185 0 0 0 0 0 0 3183 9116  2961 1  4  95
21 1 0 39156936 23887064 1780 2907  1258 3208  3208  0 0 0 0 0 0 3041 14414 3951 14 58 27
6 1 0  39156040 23688720 3653 9893  4418 8105  8105  0 0 0 0 0 0 8653 39677 7444 27 37 36
16 1 0 39137720 23788240 262  880   1418 18714 18714 0 0 0 0 0 0 4473 12819 3977 4  22 74
31 2 0 39154320 23741112 3481 5642  2624 431   431   0 0 0 0 0 0 4575 24989 6140 17 53 31
0 2 0  39157360 23673360 981  4110  888  6978  6978  0 0 0 0 0 0 3427 18723 4167 8  22 70
22 2 0 39159000 23847368 1738 5100  241  4339  4339  0 0 0 0 0 0 3567 22041 4987 16 68 16
8 3 0  39156232 23811856 1902 4420  145  893   893   0 0 0 0 0 0 2589 15951 3542 10 34 56
7 1 0  39158088 23784696 1577 3377  206  7601  7601  0 0 0 0 0 0 4795 8429  2042 7  25 68
7 3 0  39162904 23853552 155  1205  0    5954  5954  0 0 0 0 0 0 1240 4034  1639 4  14 81
2 4 0  39157480 23864216 1102 2714  206  4128  4128  0 0 0 0 0 0 2905 12484 2900 13 30 57
8 1 0  39155664 23670848 2365 3100  206  0      0    0 0 0 0 0 0 4972 10198 3692 8  30 62
5 1 0  39152568 23816440 2773 10044 412  7427  7427  0 0 0 0 0 0 5432 33765 5821 21 34 45
11 0 0 39155704 23866552 1086 3257  264  7240  7240  0 0 0 0 0 0 3983 21944 5209 18 64 18
6 2 0  39158840 23696944 5117 11435 560  2229  2229  0 0 0 0 0 0 7766 48075 10465 30 63 8
0 3 0  39159904 23711248 121  1138  61   6960  6960  0 0 0 0 0 0 2527 6363  2505  4  5  92
0 2 0  39134864 23776888 239  1436  145  27591 27591 0 0 0 0 0 0 5486 13831 4176  5  8  87
28 1 0 39156696 23838400 1309 1579  197  0     0     0 0 0 0 0 0 4125 13275 3310  13 83 4

[ 本帖最后由 linux_gao 于 2008-1-22 13:39 編輯 ]

linux_gao

我看了一下,在應(yīng)用運(yùn)行前后的swap差別不大的,很小,只有幾十M的差異,會(huì)是這個(gè)影響所致嗎?

[ 本帖最后由 linux_gao 于 2008-1-22 14:58 編輯 ]

yj11

看看磁盤IO了.看b也不小，你的r挺大．多看iostat ,如果盤多看看iostat -xmnPz 1，有沒有分區(qū)ＩＯ的問題．如果ＩＯ沒問題就看內(nèi)存，中斷，ＣＰＵ，ＰＡＧＥ，swap了．我覺得用到了swap不應(yīng)該是程序直接調(diào)，這是由操作系統(tǒng)調(diào)度的．

yj11

kernel 那么多,肯定是涉及到了系統(tǒng)底層的調(diào)度,比如進(jìn)程的調(diào)度過于多.也會(huì)造成kernel級別比較費(fèi).還有多看看man吧,連面會(huì)記的很詳細(xì)的