所有硬件资源足够，系统响应时间较长，为什么？！

冷月

最近搞性能测试，测的东西多了，也就会发现一些现象，向下面这种，什么原因呢？怎么做可以时响应时间缩短 或 再提高并发用户数呢？

测试的结果是：48个并发，响应时间4.7秒，按我们系统来说算是可以的了。

从下面的结果看：
so一直没有值，并且swpd的值还稍有减少，那就是说这段过程中没有使用交换分区，所以内存够用了；
bi和bo值小的可怜（测其他地方的时候，最大值我看到过70几兆，很明显没到磁盘处理极限），wa值偶尔有值，且很小，所以磁盘处理肯定绰绰有余；
id值最小27，也就是最大占用也才73％，我个人觉得CPU是够用的，但是 r 值有时候很大，但降下来很快，所以CPU是足够的；

也就是说数据库服务器的内存、磁盘、CPU资源都足够了，网络是局域网，并且在LR的分析器面看网页细分也没问题。

应用服务器用的是jboss，操作系统linux，应用服务器的系统资源（内存、磁盘、cpu）绝对充足，可以不考虑这个原因，jboss的线程也改在测试前调大了，也够用的。


数据库oracle，操作系统linux，vmstat命令监控系统的结果：
procs -----------memory---------- ---swap-- -----io---- --system--         ----cpu----
r  b   swpd       free    buff         cache   si   so    bi    bo         in    cs            us    sy      id     wa
0  0 108392   5604  24972 1489300    0    0     0    24       1039   269          0    0       100    0
2  0 108392   5220  24972 1489300    0    0    28   112     3209  3572       34    4       61      0
0  0 108392   5092  24972 1489300    0    0    28    92      2976  3308       36    4       60      0
0  0 108392   5092  24972 1489300    0    0     4    52       2518  2760       23    3       73      0
67  0 108392   5028  24976 1489556    0    0     8    60      3044  3827       38    5       57      0
16  0 108392   5028  24976 1489556    0    0     0     0       2858  3394      41     5       55      0
4  0 108392   5028  24976 1489556    0    0     0    24       3501  5006      30     4       66      0
0  0 108392   5028  24976 1489556    0    0     0     0        3472  5351      45     6       48      0
0  0 108392   5028  24976 1489556    0    0     0     0        2669  4377      24     4       72      0
0  0 108392   5028  24976 1489556    0    0     0    40       2098  2107        8     1      91       1
3  0 108392   5092  24976 1489556    0    0     4    24       3578  5988       30    4      65       1
3  1 108392   4324  24976 1490336    0    0   224   644     4366  7435      57    10    31       3
8  0 108392   3880  24976 1490856    0    0   120   456     4129  5566      53     8     38       1
0  0 108392   3588  24976 1490856    0    0    72   196      2091  2072      15     2     81       1
8  0 108392   3396  24976 1491116    0    0    44   160      1998  1817      12     3     84       0
28  1 108388   4472  24728 1490324    4    0   264   572    4633  5620      61     8     29       2
3  0 108388   4384  24732 1490320    0    0    80   176     3625  4136       47     6     48       0
0  0 108388   4000  24732 1490580    0    0    88   352     4613  5642       57     8     34       1
0  0 108388   6676  24720 1487732    0    0    76   196     4043  5401       53     8     38       1
1  0 108388   5860  24720 1487732    0    0    28   204     2914  3555       30     6     64       0
0  0 108388   6628  24724 1487728    0    0     8   156      2273  2152       24      4    71       0
1  0 108388   6420  24724 1487728    0    0    24   228    3303  3760        46      5    49       0
16  0 108388   6488  24724 1487728    0    0    16   120    3199  3927       38      5    57       0
0  0 108388   6424  24724 1487988    0    0    36    64      3887  5455        40     6    53       0
0  0 108388   6424  24724 1487988    0    0     0    24      1041   270           0      0    100      0
0  0 108388   6432  24724 1487988    0    0     0    12      1827  1518          13    1     86       0
1  0 108388   6512  24728 1487984    0    0     0    28      3501  4997          38     4    57       0
0  0 108388   6504  24728 1487984    0    0     0    24      2932  3734          25     4    71       0
0  0 108388   6616  24728 1487984    0    0     0     0       1033   252           0       0   100      0
18  0 108388   6560  24728 1488244    0    0    40   268    3964  5850          38     5   55       1
24  0 108388   4596  24728 1488764    0    0   152   792   4858  6898          57     9    31      3
9  1 108388   5156  24728 1489544    0    0   148   600    4901  6418          60    10   29      1
14  0 108388   4540  24732 1490060    0    0   124   692    5043  6904         57     8    33       2
0  0 108388   4220  24732 1490580    0    0   124   556     4901  5718          63    8    27       1
1  0 108388   5068  24696 1489056    0    0    80   332      4695  5496          60    8    31       1
46  0 108388   5068  24696 1489316    0    0    16   104     3231  3497          39    5    56       0
0  0 108388   5004  24696 1489316    0    0    12    92       3583  4239          46    5    49       0
20  0 108388   5068  24696 1489316    0    0     0    96       2497  2772          23    2    75       0
0  0 108388   5068  24696 1489316    0    0     0     0        1958  1728           19    2    79       0
0  0 108388   5068  24696 1489316    0    0     0    24        1014   260            0     0    100      1
44  0 108388   5168  24696 1489316    0    0     0     0         1128   421           1     0     99      0



下面有几个疑问：
  1. r值为什么偶尔会有较大值，是不是在这一瞬间处理不过来？

  2. in值算不算大？ 在系统资源基本上没用的时候，值是1000左右

  3.为什么48个并发，响应时间是4.7秒，而不是更小？现在硬件资源都还有吗？为什么没用上？如果用上了性能不会更好吗？

   上面的问题3是最重要的问题，因为我在想这个报告要怎么写，如果真的是有硬件资源而用不上的话，那么最终的决策就是改程序而不是简单的考虑增强硬件性能。

  4.什么情况下会导致有硬件资源而系统用不上的问题呢？（数据库里面的锁，我想问是否还有其他的？）

冷月

谢谢！

1qazse4

关注楼主的问题！~！

xiaoyao520

这个问题除了考虑硬件资源方面的问题之外,你还需要考虑其它方面引起的原因,辟如jboss线程数的设置不当导致请求队列.导致CPU利用率比较低.
其它的还可以考虑数据库方面引起的问题,包括驱动程序或锁的问题,但这些问题一般都可以查看后台信息可以获得的.

冷月

我也在想jboss线程数和数据库锁的问题，不过我想，当时在测试之前就已经把jboss的线程数范围扩大改到几百了，应该是够用的，不过我对jboss不是很了解
数据库锁的问题，我在测试的过程中，根据网上的写的一些查锁的sql查过，没发现什么被锁上啊

大家继续，集思广义