|  | IBM WebSphere Application Server 常见问题及解答专题是关于 IBM WAS 产品家族的问题集锦，其中收集了客户在使用此产品时遇到的一些常见问题。这本问题解答可以被看作是对产品使用手册以及 WebSphere Application Server 在线信息中心的补充。WAS 故障诊断的常用工具有哪些？
问题：运行应用程序所需 CPU 的最小数量和最大数量是多少？
答：
现代操作系统通常在进程调度方面表现得很出色，从而最大程度减少了上下文切换。上下文切换是在操作系统调度程序用另一个进程替换 CPU
上正在运行的一个进程时发生的，而且是各种因素作用的结果，例如作业（或进程）优先级、是否等待其他资源（如
I/O）、进程是否将用完所有分配给它的 CPU
周期（时间片）等。但是，在执行上下文切换时，虽然现代操作系统表现很“出色”，却并非“完美无缺”，因为进程在每次进行上下文切换时，它都将停止运行——这将导致吞吐量出现延迟（和性能下降）。如果我们确实不希望出现任何上下文切换，则系统中的
CPU 数要大于该系统中运行的进程数。而这完全不切合实际，因为在一个系统中安装这么多的
CPU，几乎没有任何组织能负担得起，而且也没有必要，因为大多数进程都不要求对 CPU
进行持续访问。因此，我们应该转而研究一些最重要的进程，这些进程在本文中即指系统中应用服务器运行时所使用的JVM。
起初，我们假定每个应用服务器 JVM 应该采用至少一个
CPU；这样就有可能最大程度减少发生上下文切换的次数——至少就将用完时间片这一因素而言是如此（如上所述，导致上下文切换还有其他因素）。但是除非您在运行所有服务器时占用了全部
CPU 资源，否则，在应用程序请求（该请求随即被转换为对操作系统资源的请求）到达应用服务器时，很可能存在可用的 CPU
周期。因此，运行的应用服务器数量有可能大于 CPU 数量。
不过，如果要获得可以在环境中运行的服务器的准确数量，则还得采用视情况而定
之类的方式进行回答。这是因为该数量实际上取决于负荷、应用程序、吞吐量和响应时间要求等，确定这个准确数量的唯一方法是在环境中运行测试。
在开发环境（其中负荷可能是每个应用服务器只有一个用户）中，您会期望每个 CPU
运行的应用服务器实例数量是生产环境中的应用服务器数量的数倍，这种想法很合理。尽管如此，也很难确定具体的应用服务器数量，虽然为所有应用服务器添加足够的内存也是个相当重要的因素。根据经验，所有
WebSphere Application Server JVM 进程加在一起的大小不应超过服务器上未使用物理内存的
80%。在计算该数字可以达到的最大数目时，您必须考虑的不仅有最大堆大小，而且还有除最大堆大小之外的 Java?
字节码解释器的进程大小（这个大小在操作系统进程表中列出）。字节码解释器向进程表大约添加 65MB（除了最大堆大小 128MB
之外），并随最大堆大小的增加而增加。
在解决了 CPU 的最小数量后，您可能要问，最大 CPU 数量是多少？
如果您了解到回答也是视情况而定，那不必感到惊讶。一个非常高效且经过精心编写的应用程序只通过一个应用服务器进程即可使用多个
CPU。事实上，WebSphere Performance Lab 在运行涉及 Trade 性能基准时，使用了 12 个
CPU（有时更多）。而期望大多数应用程序具有这种伸缩性可能是不合理的，但大多数经过精心编写的应用程序都应能通过应用服务器使用多个
CPU（实际上，只使用一个 CPU 通常表示存在应用程序瓶颈）。在任何情况下，由 Tom Alcott 在WebSphere
Scalability
一书讲述的确定最佳克隆（或应用服务器实例）数的指导原则仍然适用：
一般情况下，您应调整一个应用服务器的实例来观察吞吐量和性能，然后逐步增加克隆数量，在添加每个克隆时，对性能和吞吐量进行测试。通过这种方式，可以确定为环境提供最佳吞吐量和性能所需的克隆数。通常，在
CPU 利用率达到稍微低于 75% 时，可以通过另添加克隆来提高吞吐量。
而且如您所见，对此问题的最终回答还是视情况而定。
本答案，来自IBM WebSphere 开发者技术期刊
中的来自
Tom Alcott 的评论:欲言又止的 WebSphere Application Server 的相关问题
返回“WebSphere
Application Server 常见问题及解答”专栏。
| |
| |
|
