GC_*_*GC_ 6 performance performance-monitoring cpu-usage mainframe zos
我正在使用在 OMVS 中的 tomcat 上运行的应用程序。它在一台大型机上运行得非常糟糕，在另一台大型机上运行得非常好。有没有办法比较两台主机的CPU作为参考？
我试过：
/d m=cpu
我没有发现结果很有希望。我们的迷你系统和我们的主系统的结果似乎是一样的。我认为迷你实际上更有限。
注意：我正在寻找更多关于这个特定 LPAR 的 CPU 处理能力。
GC_
小智 9
比较大型机映像的 CPU 数量很可能没有意义。大型机旨在同时运行多个任务，并优先考虑业务所说的最重要的内容，并且能够高度虚拟化，因此查看 CPU 的数量并不能告诉您太多信息。您必须了解应用程序周围的环境，其中包括分配给 LPAR 的权重（保证 LPAR 对逻辑 CPU 的访问量）、同时在 LPAR 上运行的其他事物，以及其他正在运行的事物同时位于同一 CEC 上的其他 LPAR。您还需要了解 LPAR 的 WLM 策略，因为它告诉 z/OS 哪些应用程序目标最重要，哪些不太重要。
请注意，大型机性能分析是一项专业技能，人们需要花费数年时间学习，因此通过 stackexchange 可以表达的内容是有限的。与您的系统程序员/性能分析师交谈可能比尝试自己弄清楚要好得多，而不是纯粹的学习练习。
也就是说，我可以给你一些基本的东西来看看，或询问。您可能无法访问我将提到的某些数据/工具。
首先，也是最基本的，所有大型机都能够在 SMF 70-79 记录中收集性能数据，我们建议商店将其作为常规做法收集，如果您想获得真正低级的 SMF 113 记录。然而，它们是二进制记录，不容易理解，但它们就在那里。它们的格式记录在 z/OS MVS 系统管理工具 (SMF) 一书中。
接下来，有许多工具可用于对 RMF 记录进行后处理，例如来自 IBM 的 RMF，以及各种供应商工具。如果您可以访问它们，您可以获得有关各种地址空间/进程随时间推移的 CPU 利用率的非常深入的信息。一些工具还具有交互模式，您可以在其中获取单个 LPAR 活动以及整个 CEC 活动的实时快照。SDSF 和 EJES 还可以为您提供有关 LPAR、CEC 和运行地址空间的一些非常基本的信息，例如，您可以查看累积的 CPU 时间。如果您能告诉我们您可以使用哪些工具，我们或许可以为您提供更具体的建议。
不过，据猜测，虽然两个映像定义了相同数量的逻辑 CPU，但主系统的权重比迷你系统高得多，这意味着主系统可以保证访问比迷你系统更多的 CPU 容量，大多数时候，迷你系统不能也不会尝试将工作实际分配给大多数 CPU。如果您在 z13 上运行并且处于 PROCVIEW CORE 模式，/dm=cpu 命令将告诉您的一件事是 CPU 是停放还是未停放。停放的 CPU 是 z/OS 映像不会将工作分派到的 CPU，因为拥有它们的系统（可能是主系统，如果两者都在同一个 CEC 上）正在向它们分派工作。
小智 9
Kevin 提到了许多重要的观点，但从更高的层次开始分析可能会有所帮助：两台机器是什么，因为我们谈论的是在 JVM 中运行的 Tomcat，所以两者都有 zAAP 或 zIIP（假设zIIP 上的 zAAP）？
从“dm=cpu”你应该能够获得机器型号信息，这至少会让你知道你是否真的在比较苹果和苹果。这是我笔记中的一个古老的例子：
D M=CPU
IEE174I 13.15.43 DISPLAY M 443
PROCESSOR STATUS
ID CPU SERIAL
00 + 0xxxxx2817
01 + 0xxxxx2817
02 -
03 N
04 N
05 N
06 N
07 N
08 NI
09 NI
0A NI
0B NI
CPC ND = 002817.M15.IBM.02.0000000xxxxx
CPC SI = 2817.403.IBM.02.00000000000xxxxx
这里的关键点：xxxxx 是（此处隐藏的）序列号。2817 是型号，相当于 z196，今天在 2016 年比当前的 z13（型号 2964）早了两代。型号的意义非常有限：您必须查找它们。但如果有问题的两台机器是不同的型号，那就是差异的一部分。
CPC ND 线上的“M15”表示安装了多少书本/抽屉，在这种情况下这可能是一个次要的考虑。
CPC SI 线上的“403”虽然很重要。“4”表示通用 (GP) 发动机的相对速度。对于较大的（以前称为企业级）机器，这可以从 4（最慢）到 7（最快）。对于较小的（过去称为“商务级”）机器，速度指示器从 A（最慢）到 Z（最快，但比同代机器的 7xx 慢）。“03”表示机器上可用的 GP 数量。对于少于 100 个 GP 的常见配置，这只是一个十进制数。因此，在本例中，机器是带有 3 个 GP 的 z196，在这一代机器上以最慢的速度运行。
但是，您提到了 Tomcat，并且由于 Tomcat 在 JVM 中运行，因此大部分 CPU 时间实际上应该在专用引擎上--zAAP 或 zIIP，假设 A) 在机器上购买此类，并且 B) 它们已配置正确地传递到 LPAR。无论通用发动机的速度如何，专用发动机都会全速运行。IE zIIP 始终以 7xx 速度运行，即使它们在 4xx 机器上也是如此。
如果您尝试在没有专用引擎的情况下运行 Tomcat……那么，如果您使用的是子容量（而不是 7xx）机器，这可能不太好，原因可能与可能的可用容量和软件成本有关.
但是，请注意，即使 Tomcat 的大部分 CPU 时间将卸载到 zIIP/zAAP（如果可用），仍然会有一些时间在 GP 引擎上运行，这使得理解 GP 情况也很重要。根据配置，在 GP 上运行的数量可能低至总量的 1-2% 或可能大于 10%。
请注意，在上面的显示中，zIIP 是 CPU 08-0B，但它们“N”不可用。在这种情况下，它们被定义到 LPAR，但它们目前在硬件上不可用，因为这是一台 DR 机器，在创建快照时没有适当的 CBU 配置。不幸的是，这些只是逻辑 zIIP，物理 zIIP 或 zAAP 的数量无法从该显示中获得，实际上很难追踪。但是，如果您在线拥有逻辑 zIIP/zAAP，您就会知道您至少有一些物理引擎来支持它们。
即使有问题的两台机器是同一代、相同的速度设置和相同数量的引擎（GP 和 zIIP），也会围绕大型机很少运行单个系统这一事实产生大量问题/问题——通常有多个 LPAR 同时运行。在这种情况下，您必须开始深入研究 Kevin 提到的数据，以了解真正发生了什么。但是，如果您将苹果（2964-605，带 zIIP）与香蕉（2828-F03，不带专用引擎）进行比较，您应该从一开始就预期性能差异。
最后，我应该指出，相对于机器的生成，所使用的 Java 版本也很重要。例如，如果有问题的两台机器是 z13s，但一个 Tomcat 使用 Java 8，另一个使用 Java 7，我预计会有差异，因为新 z13 指令的利用仅在 Java 8 中。
所有这些都只关注与 CPU 相关的性能问题。显然，您在其他地方也可能有分歧和问题。但是 CPU 是开始寻找缺少任何其他信息的好地方。
我已经成功地在 z/OS 上运行了 Tomcat，几乎没有任何问题——但是我有足够的 zAAP/zIIP 容量可用。