<解决中><请教>disk busy 100% 解决及调优

vanvesee

多发了一次，谢谢各位的回答～:wink:

[ 本帖最后由 vanvesee 于 2008-11-1 00:09 编辑 ]

vanvesee

2.存储是fast_write

Disk    Busy%     KBPS     TPS KB-Read KB-Writ  PgspIn       55  % Noncomp  72.9
hdisk4  100.2    13.6K   467.3  5342.1  8612.7  PgspOut       0  % Client   72.8
hdisk9  100.2    13.5K   438.9  5204.5  8664.3  PageIn     8923
hdisk8  100.2    12.8K   399.0  5004.0  8146.1  PageOut   12530  PAGING SPACE
hdisk5   99.2    14.2K   502.7  5676.8  8868.3  Sios      21142  Size,MB   20480
hdisk7   99.2    13.7K   441.4  5741.1  8307.2                   % Used     18.9
hdisk6   99.2    12.8K   444.4  5319.2  7838.7  NFS (calls/sec)  % Free     81.0
hdisk0   15.4    107.7    26.9   107.7     0.0  ServerV2       0
hdisk1   10.9    113.7    28.4   113.7     0.0  ClientV2       0   Press:
hdisk3    0.0      0.0     0.0     0.0     0.0  ServerV3       0   "h" for help
dac1      0.0    80.7K  2692.8   31.5K   49.2K  ClientV3       0   "q" to quit
hdisk2    0.0      0.0     0.0     0.0     0.0
cd0       0.0      0.0     0.0     0.0     0.0

这个是正常工作期间

4.顾问说是pop3协议的问题
由于用户都使用的Foxmail自动接收 所以1.5w-2w人 平均5分钟轮询次 压力蛮大
而且停止某个分区上的pop3协议后 Busy%确实下降很多

vanvesee

如何看出来的？
存储上的瓶颈如何调优？
望赐教

vanvesee

没有。。 顾问最近过来升级了Domino到7 参数配置了下
两台服务器其中一台比以前性能好了
不过另外一台（用户数较多的）I/O Wait% 反而提高了。。

vanvesee

不清楚。。  不知道主机部的人之前装过什么  
其实我是在偷偷研究 按理说我根本没有权力对这些服务器做调整的

vanvesee

原帖由 chalylau 于 2008-11-1 23:42 发表
瓶颈应该在存储上。

主机部已对硬盘进行升级
现在可以肯定问题不是出在存储上

Network  KBPS   I-Pack  O-Pack   KB-In  KB-Out  Waitqueue  
en0    2174.4   1045.8   430.3    59.2  2115.2
en3      19.8    167.2     0.0    19.8     0.0

主机部的人认为是我们程序应用的问题。。

vanvesee

文件系统我没有参与配置也无权做调整的
- -
也许跟你遇到的只是现象类似而已

vanvesee

我再查查应用配置有没有什么不足之处

vanvesee

mServer1/#vmstat 1 10

System configuration: lcpu=8 mem=23808MB

kthr    memory              page              faults        cpu   
----- ----------- ------------------------ ------------ -----------
r  b   avm   fre  re  pi  po  fr   sr  cy  in   sy  cs us sy id wa
1 24 2628196  5243   0  11   0 2802 5308   0 2492 27559 9531 27 21  2 49
3 29 2628196  9081   0   4   0 539  960   0 2172 27711 14284 35 18  0 46
1 18 2628197  9179   0   2   0   0    0   0 1170 19712 12045 15 10  2 73
1 22 2628231  7355   0   2   0   0    0   0 851 12061 6201 13  7 10 69
3 28 2628233  9460   0   5   0   0    0   0 1806 17496 10904 26 10 14 51
1 25 2628233  8056   0   3   0   0    0   0 1615 14092 10392 11  8 23 57
0 30 2628242  6081   0   9   0   0    0   0 1449 14037 6795 15 11 17 56
2 32 2628251  6112   0   5   0   0    0   0 1629 15650 6835 28 13  7 52
3 30 2628271  5222   0  10   0 1531 2509   0 1922 18817 7743 23 15 13 48
1 31 2628266  5121   0   1   0 2149 3528   0 2899 20500 8371 27 16  3 53

发现b（取样时间间隔内的置于 VMM 等待队列（等待资源、等待输入／输出）的平均内核线程数）远远大于r。
引用： “r 应该始终高于 b；如果不是，通常意味着遇到了 CPU 瓶颈。”

vanvesee

mServer1/#vmstat 2 10

System configuration: lcpu=8 mem=23808MB

kthr    memory              page              faults        cpu   
----- ----------- ------------------------ ------------ -----------
r  b   avm   fre  re  pi  po  fr   sr  cy  in   sy  cs us sy id wa
9  7 2462494  5197   0   0   0 3147 7339   0 1814 47667 9818 40 52  2  6
9  8 2462532 24522   0   0   0 4689 11474   0 1855 41087 12241 35 46  2 17
5 12 2462582  5399   0   0   0   0    0   0 1347 31271 11430 23 36  4 37
4 10 2462610  6840   0   0   0 1612 3981   0 1728 39396 10761 31 49  3 17
6  6 2462645 39296   0   0   0 7803 19333   0 1990 42204 11726 27 51  3 18
3  8 2462688 22073   0   0   0   0    0   0 1267 29107 11569 29 32  5 34
5 11 2462704 24454   0   0   0   0    0   0 1276 34165 10369 33 37  2 27
5 10 2462749 32570   0   0   0   0    0   0 1541 36384 11295 30 42  2 26
3  7 2462770 23075   0   0   0   0    0   0 854 21648 10511 37 22  5 36
7  8 2462841 25400   0   0   0   0    0   0 1320 33981 10275 44 37  3 16

这是之前的数据，差别这么大。。