急性者的 WebSphere 优化：如何通过 20% 的工作获得 80% 的性能改善-2

look_w

环境卫生获得性能基准数在进行任何更改之前，获得性能基准数是很重要的，因为只有与基准进行比较才能确切说明系统变快还是变慢。在运行基准测试或其他性能测试时，必须谨慎地控制系统上的其他工作。例如，如果您的数据库用于事务处理和繁重的决策支持 (DSS) 查询，则可以确定非预定的 DSS 查询将牺牲您的事务性能。如果您在不知道 DSS 会有干扰时试图优化此环境，则将错误地得出结论：系统的性能“已优化，但不可预测”。实验示例的性能基准（使用 JMeter）如下面的图 1 所示。可以通过 Run 菜单下拉列表启动一项测试或清除先前的所有数据以进行下一次测试。
图 1. 使用 JMeter 的性能基准：37 毫秒响应时间基准性能表明平均响应时间为 37.6 毫秒（请看 JMeter 帧的右下角）。您可以对不同的度量进行优化，例如吞吐量、中值响应时间、响应时间偏差或其他某种优化目标。首先确定优化目标，然后弄清楚如何优化系统才能实现此目标。
如果工作负载很大而且系统优化不好，则需要花很长时间才能获得基准性能值。您可以使用小型测试工具来缩短一些早期测试的时间，还可以获得系统输出的详细信息。确保数千次点击的次秒级响应不会只是应用程序错误页面的详尽测试。JMeter 提供测试活动日志。您可以定义一个文件（例如 /tmp/jmeter.out）来包含 HTTP 请求响应活动的返回代码。
在下面的下载部分，您将发现 JMeter 的两个不同的测试文件。一个是完全测试，另一个标为“Small”。Small 测试也启用了输出收集功能，以便您可以看到请求-响应的结果。在实验测试中，计算机是完全满负荷的——图 1 右下角的蓝色实框表示 100% 的 CPU 使用率。图形指示器和运行 top 命令的 xtermBoth 都指示 CPU 使用率的问题。查明什么占用了 CPU 时间需要费些周折。
没有足够的 CPU 和内存，服务器（WebSphere Application Server 或其他任何服务器）将不能很好地运行。如果您在没有空闲 CPU 时或者在操作系统需要交换虚拟内存的地方试图优化服务器，则无法使其变得很快。下一部分将描述如何检测 CPU 或内存受限的系统以及如何修复它们。
优化日志一些优化更改将使系统运行得更快，而一些将使之运行得更慢。记录您做了什么更改以及为什么这样更改将使优化过程更简单也更顺利。下面是一个非常简单的配置日志——格式不是很重要，只要您每次记录一些关键数据点即可。一个好的过程是将更改作为注释放在配置文件中。
示例优化日志条目

1 2 3 4 5 6

DateTime:_____________   Name:_____________________ Parameter Changed____________________________________ Why?________________________________________________ How?________________________________________________ New Performance____________________________milliseconds Keep____________ Remove_____________ How?___________

CPU 使用率在进行任何优化前，系统必须有可用的 CPU 周期。任何在服务器上运行的不是很有用的程序都应该停止或禁用——包括在服务器上运行的漂亮屏幕保护程序！检测 CPU 受限的系统的最佳方式是运行 top 命令——它是 Linux/Unix 性能工具的“瑞士军刀”：
图 2. top 命令在右上角，“idle”处于 0.0%，所以我们知道计算机已竭尽全力在运行。“COMMAND”栏中的进程列表显示占用最多 CPU 周期的两个程序称为 wastecpu。如果您阅读清单 2 中的注释，您会发现可以将 wastecpu 杀死。
清单 2. wastecpu 源代码

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

/* if you read this comment before you killed "wastecpu" you did good! Wastecpu is meant to simulate a "production application" and the purpose is to train people not to kill ANYTHING without knowing what it does. */ #include <stdio.h> main() { int i; for (i=0;i<1;i=0) { /* wow, what a useful program */ i=0; } } /* end of main */

在运行 top 命令时，要杀死这些模拟的 CPU 贪吃户，请按 K 键，top 将询问您要杀死什么进程。输入进程 id (PID)（在本例中为 2441），然后 top 将停止此程序。再次执行此操作来杀死第二个副本 PID 2442。要避免以后还要处理 wastecpu 程序，请在 go_trade6 脚本中将其注释掉。
在一些生产环境中，发生问题时除了“抛弃硬件”外别无他法。有许多选择可以进行纵向和横向扩展。图 3 阐释了用于在实验环境中添加另一个处理器的配置。交叉电缆在学员小组（高度竞争的学员的一个重要特征）之间提供“气隙 (Air Gap)”安全性。
图 3. 测试实验中两台 ThinkPad 的 Trade 6 配置内存使用率在有足够内存时，WebSphere Application Server 执行得最好。您可以通过 top 命令查看内存使用率。“交换”域应该为零——如果不是，则操作系统正在通过磁盘空间模拟有更多的 RAM 的情况，这当然是一个很慢的过程。使用 vmstat 命令可以更详细地检查内存情况。下面的图 4 中的 vmstat 输出表明系统不堪重负。“si”和“so”栏（swap-in 和 swap-out）与零相去甚远。此计算机需要更多的内存或者减少正在运行的程序。有关“si”和“so”的更多信息，请使用 man vmstat 获得。
图 4. 内存不足的系统——“si”和“so”应该为零运行服务器或者使用 VMWare 教授实验的最好做法就是“升级”内存时不用打开计算机。只需关闭客户操作系统 (guest operating system)，将设置更改为使用全部内存，然后启动虚拟机，如下面的图 5 所示。如果虚拟机需要比运行主机操作系统更多的内存，则程序运行仍然会很慢。如果有人能够发明一个系统，它可以模拟的内存比硬件中现有的内存更多，则这些程序将会执行得非常好！
图 5. VMWare 工作站中的内存升级其他环境因素环境中有许多其他因素会影响性能，包括网络使用率、服务器上的其他程序、拒绝服务攻击以及电源线被绊断。请确保您的操作系统针对工作负载进行了优化。您需要修改 Linux 上的 sysctl、Solaris® 上的 /etc/system，以及AIX® 上的一组参数（请参阅下面的）。
数据库管理员 (DBA) 能够对性能优化做出很大的贡献。除了调整数据库参数外，DBA 可以识别出编得不好的查询和死锁生成器，这种反馈对提高性能是很重要的。DBA 还有一些灵活的工具，例如 DB2 Health Center，它可以识别问题并生成脚本来修复这些问题。DB2 Performance Adviser 和 Index Adviser 也使 DB2 数据库优化变得更容易。要打开 DB2 Health Center，您可以从命令行输入 db2hc，或者单击 DB2 Command Center 中的 Health Center 图标。下面的图 6 显示了 DB2 Health Center 生成的一个警报，图 7 显示了它为更大的锁列表提供的一个建议：
图 6. 正在运行的 Health Center：生成一个警报图 7. 正在运行的 Health Center：推荐解决方案应该捕获图 7 中建议的命令并将其放在一个脚本文件中。当凌晨两点试图恢复系统时是没有地方获得 GUI 的！所有的一切都需要放在脚本中。