CPU或networkingI / O绑定？

我试图找出我的服务器是networkingIO绑定还是CPU绑定。我查看了一些典型工具的输出以检查系统的当前状态（输出iostat，sar和top在下面），但是我不太确定我的解释是否正确。

这是我的设置：

应用程序服务器（其中2个）：（Debian，JBoss），四核，16 GB RAM
数据库服务器：（Suse，MySQL），四核，64GB RAM
从应用程序服务器到数据库服务器的通信通过防火墙（能够达到100 Mbit）

服务器在做什么：

部署在JBoss中的应用程序读取大量的文本文件，执行一些合理性检查（涉及与数据库交谈），最后将文本文件中的数据存储在数据库中

为了提高吞吐量，我们只安装了4个额外的JBoss实例，所以现在有5个应用程序执行导入（无集群）。不幸的是，performance并没有像我希望的那样有所提高。

这些是我迄今在数据库服务器上收集的统计数据：

最佳：

top - 14:09:28 up 27 days, 9:45, 1 user, load average: 0.65, 0.69, 0.83 Tasks: 92 total, 1 running, 91 sleeping, 0 stopped, 0 zombie Cpu(s): 10.8% us, 1.1% sy, 0.0% ni, 85.5% id, 1.7% wa, 0.1% hi, 0.8% si Mem: 65884336k total, 61751244k used, 4133092k free, 524752k buffers Swap: 8388600k total, 1097864k used, 7290736k free, 32520508k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 9187 mysql 16 0 26.8g 26g 4168 S 49.3 41.7 12455:36 mysqld 1 root 16 0 656 88 56 S 0.0 0.0 0:06.30 init 2 root RT 0 0 0 0 S 0.0 0.0 0:00.62 migration/0 3 root 34 19 0 0 0 S 0.0 0.0 0:00.03 ksoftirqd/0

所以数据库服务器是非常闲置的，我没有进一步调查。

这些是我迄今在应用程序服务器上收集的统计信息：

最佳：

 top - 14:31:11 up 43 days, 23:25, 1 user, load average: 7.31, 7.13, 6.90 Tasks: 87 total, 2 running, 85 sleeping, 0 stopped, 0 zombie Cpu(s): 58.0%us, 3.9%sy, 0.0%ni, 35.7%id, 0.0%wa, 0.1%hi, 2.2%si, 0.0%st Mem: 16440520k total, 15894640k used, 545880k free, 79580k buffers Swap: 8192616k total, 56k used, 8192560k free, 2968948k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 8318 lvs 18 0 2773m 2.2g 13m S 101 14.0 1233:34 java 8367 lvs 18 0 2752m 2.2g 13m S 65 13.9 1217:41 java 8118 lvs 18 0 4731m 2.2g 13m S 58 14.2 1201:01 java 8278 lvs 18 0 2755m 1.9g 13m S 21 12.3 1212:48 java 8411 lvs 20 0 2743m 2.1g 13m S 8 13.4 1206:58 java 1 root 18 0 6124 676 560 S 0 0.0 0:04.10 init 2 root RT 0 0 0 0 S 0 0.0 0:01.18 migration/0 3 root 34 19 0 0 0 S 0 0.0 0:00.12 ksoftirqd/0

这里的负载平均值相当高，也是CPU的利用率。令我困惑的是，CPU利用率并不是一直很高。这是我使用iostat观看CPU使用20秒时得到的结果：

 lvs@ftpslavedev:~$ iostat -c | head -3 ; iostat -c 1 20 | grep "^ *[0-9]" Linux 2.6.18-6-amd64 (ftpslavedev) 10/07/09 avg-cpu: %user %nice %system %iowait %steal %idle 2.40 0.00 0.34 0.16 0.00 97.10 58.00 0.00 4.00 0.00 0.00 38.00 50.62 0.00 3.23 0.00 0.00 46.15 35.16 0.00 3.49 0.50 0.00 60.85 75.43 0.00 5.46 0.00 0.00 19.11 72.07 0.00 2.49 0.25 0.00 25.19 50.12 0.00 4.24 0.00 0.00 45.64 50.25 0.00 1.00 0.00 0.00 48.75 32.18 0.00 3.71 0.00 0.00 64.11 51.74 0.00 1.99 0.00 0.00 46.27 53.12 0.00 2.99 1.00 0.00 42.89 47.64 0.00 2.73 0.00 0.00 49.63 13.18 0.00 2.74 0.00 0.00 84.08 0.00 0.00 2.24 0.00 0.00 97.76 0.25 0.00 3.23 0.00 0.00 96.52 0.00 0.00 2.74 0.50 0.00 96.77 0.00 0.00 2.99 0.00 0.00 97.01 17.41 0.00 2.74 0.00 0.00 79.85 23.19 0.00 2.99 0.75 0.00 73.07 23.33 0.00 3.23 0.00 0.00 73.45

由于CPU使用率并不高，我想知道应用程序服务器和数据库之间的通信是否会成为瓶颈并使用sar：

 lvs@ftpslavedev:~$ sar -n DEV | head -3 && sar -n DEV 1 20 | grep "eth0.*[1-9]" Linux 2.6.18-6-amd64 (ftpslavedev) 10/07/09 00:00:01 IFACE rxpck/s txpck/s rxbyt/s txbyt/s rxcmp/s txcmp/s rxmcst/s 16:55:30 eth0 22562.00 21297.00 9632456.00 5156549.00 0.00 0.00 0.00 16:55:32 eth0 19690.10 18800.00 8496563.37 4558991.09 0.00 0.00 0.00 16:55:34 eth0 22716.00 21214.00 10610874.00 5378377.00 0.00 0.00 0.00 16:55:36 eth0 17737.62 16509.90 9027099.01 4784231.68 0.00 0.00 0.00 16:55:38 eth0 10749.69 9625.79 6233610.69 2357184.91 0.00 0.00 0.00 16:55:39 eth0 20929.70 21002.97 5359857.43 4705525.74 0.00 0.00 0.00 16:55:41 eth0 17462.38 17476.24 6281078.22 5062188.12 0.00 0.00 0.00 16:55:44 eth0 19410.19 19368.52 4770402.78 3916590.74 0.00 0.00 0.00 16:55:46 eth0 13388.12 13277.23 3501303.96 2883294.06 0.00 0.00 0.00 16:55:48 eth0 25988.12 24862.38 10358798.02 5966493.07 0.00 0.00 0.00

rxbyt / s和txbyt / s中的值是每秒字节数。如果我把它们转换成每秒兆位，我会得到类似的东西

 rxbyt/sr Mbits/s txbyt/st Mbits/s 9632456 73,49 5156549 39,34 8496563 64,82 4558991 34,78 10610874 80,95 5378377 41,03 9027099 68,87 4784231 36,50 6233610 47,56 2357184 17,98 5359857 40,89 4705525 35,90 6281078 47,92 5062188 38,62 4770402 36,40 3916590 29,88 3501303 26,71 2883294 22,00 10358798 79,03 5966493 45,52 3694266 28,19 2192922 16,73

所以在这里我们经常有> 60 Mbit的值。鉴于我们的第二个应用程序服务器做了完全相同的事情，我认为很可能是我们的防火墙（如前所述只能够处理100兆比特）可能是服务器上的高负载平均值的真正原因，因此甚至增加更多的服务器对我们无能为力。

我不知道我对这些数据的解释是否真的合理，所以感谢您对此的评论。

最好的祝福，

斯特凡

嗯，复杂的问题： – /。一点：

我认为很可能是我们的防火墙（如前所述只能处理100 Mbit）可能是服务器平均负载高的真正原因，因此即使增加更多的服务器也无济于事。

如果防火墙阻止数据传输，则不会看到高CPU负载（上面的％用户）; 相反，你会看到更高的％iowait（包括networkingI / O）。所以这似乎不太可能（除非应用程序进行某种投票）。

我认为你最好的做法是更仔细地检查应用程序服务器上的高％用户; 做一些分析，找出什么时候加载CPU的应用程序。这应该给你一个线索。

当你接近它的容量时，防火墙也许值得研究。

你为什么不看数据库服务器端的stream量？如果你的防火墙具有snmpfunction，你应该能够看到它的负载，如果没有其他的话，至less在内外接口之间的区别。这应该给你一些想法。另外，虽然你说它有100mbit的能力，但它仍然不清楚每秒能处理多less包。这也是要记住的。