ibm i2_IBM I等待会计
IBM I等待会计
IBM i 等待记帐是IBM i操作系统中内置的一项技术，可以识别不使用CPU的线程或任务在做什么。 因为线程和任务等待的原因多种多样，所以等待计费可以成为一种非常强大的功能，有助于理解等待条件，并有可能消除或减少等待时间，这可能会对性能产生重大影响。
本文介绍了什么是等待计费，并解释了为什么线程等待以及如何使用等待计费来解决性能问题或提高应用程序的性能。
让我们从回顾一些术语开始。
- 作业是一种构造，通过该构造可以在系统上完成所有工作。 每个作业至少有一个线程，并且可以有多个线程。
- 线程是作业中执行的单元； 所有作业都有至少一个线程，并且可以有许多线程。 线程具有支持操作系统和应用程序使用它们的结构。
- 许可内部代码（LIC） 任务是没有IBM i作业或线程级结构的执行单元。 每个线程都由一个任务表示，但是任务也独立存在，而没有IBM i线程级构造。 LIC任务通常在外部不可见，除非通过IBM i性能工具或服务工具。 可以显示LIC任务的唯一操作系统命令是“使用系统活动” （WRKSYSACT）。
等待计费概念适用于线程和任务。 在谈论可执行工作单元时，会使用术语线程和任务。
线程或任务可以处于以下两种状态之一。
- 在处理器上运行； 这是运行状态。
- 等待在处理器上运行。
当线程或任务正在等待在处理器上运行时，存在三种不同类型的等待：
- 准备运行，等待处理器：这是一种特殊的等待状态，通常称为CPU排队 ； 线程或任务已排队，等待在CPU上运行。 CPU排队有几种不同的原因。 最常见的情况是当CPU容量过大并且正在忙于处理优先级较高的工作时。 结果，优先级较低的任务和线程必须等待队列才能使CPU可用。
- 空闲等待 ：空闲等待是正常且预期的等待条件。 当线程正在等待外部输入时，将发生空闲等待。 输入可能来自用户，网络或其他应用程序。 在收到输入之前，无法完成任何工作。
- 阻塞的等待：阻塞的等待通常是序列化机制的结果，该机制用于同步对共享资源的访问。 阻塞的等待可能是正常的和预期的-例如，对更新表中的行进行串行访问，磁盘I / O操作或通信I / O操作。 但是，如果由于序列化而导致正常的等待条件太多，那么他们的分析可能会为改进应用程序设计以提高并行度提供深刻见解。
阻塞的等待也可能不正常； 等待计费可以用来识别意外的阻塞点，然后可以对其进行分析以了解为什么发生等待，以及如何减少或什至消除等待条件。
操作系统会一直为所有线程和任务自动完成对等待信息的识别和跟踪。 因此，您需要进行等待分析的信息始终可用。
等待桶
IBM i操作系统中几乎所有的等待条件都已被识别和枚举–也就是说，每个唯一的等待点都分配有一个数值。 这是可能的，因为IBM可以完全控制LIC和操作系统。 另外，操作系统的体系结构是高度组件化的，并且存在用于各种序列化机制的定义明确的接口。 截至IBM i 6.1发行版，共有268个独特的等待条件！ 跟踪每个线程和任务的250多个独特等待条件将消耗过多的存储空间，因此已使用了分组方法。 每个唯一的等待条件都分配给32个组或“存储桶”之一。 当线程或任务进入和退出等待条件时，任务调度程序会将等待条件映射到适当的组。
了解等待计费可以帮助您更好地理解可以使用Performance Data Investigator工具显示的性能图表以及解释正在查看的数据的方式。
等待时段描述部分回顾了IBM i 6.1和7.1版本中存在的32个等待时段。
运行等待时间签名
您可以以图形方式考虑线程或任务的生命周期，从而节省了运行或等待所花费的时间。 这种图形描述称为运行等待时间签名 。 在较高级别上，此签名如下所示：
图1：运行等待时间签名
传统上，提高应用程序性能的重点是使它尽可能高效地使用处理器，或者拥有更多和更快的处理器。 在具有等待计费功能的IBM i上，我们可以检查等待时间，并了解造成等待时间的原因。 如果有一些等待因素可以减少或消除，那么整体性能也可以得到改善。
如果我们使用等待记帐来获取运行等待时间签名，则现在可以识别出构成线程或任务等待时间的组件。
图2：运行等待时间签名组件
例如，如果线程的等待时间是由于在磁盘上读取和写入数据，锁定记录以进行序列化访问以及记录数据而造成的，则我们可以看到上述等待已中断。 当您了解所涉及的等待类型时，您可以开始问自己一些问题。 对于上面的示例，可以提出以下问题：
- 磁盘读取是否导致页面错误？ 如果可以，我的内存池大小是否合适？
- 哪些程序导致磁盘读写？ 是否有可以减少或消除的不必要的I / O？ 或者，是否可以以某种方式（例如，异步）完成I / O操作，以使它们不会影响线程或任务的运行时间？
- 我的记录锁定策略是否最优？ 还是我不必要地锁定记录？
- 正在记录哪些文件？ 是否需要所有日记帐并对其进行最佳配置？
在IBM i 6.1发行版中，已经定义了32个等待组或存储桶 。 等待组的定义因发行版本而异，并且将来可能会更改。 在本文的最后，您可以找到32个等待组的列表以及每个等待组的高级描述。
当您在应用程序上进行等待分析时，这些等待组中的许多可见。 了解您的应用程序在做什么以及在这种情况下为什么等待，可以帮助您减少或消除不必要的等待。
持有人和服务员
IBM i不仅会跟踪线程或任务正在等待的资源，而且还会跟踪已为其分配资源的线程或任务。 这是一个非常强大的功能。 持有者是使用序列化资源的线程或任务。 服务员是想要访问该序列化资源的线程或任务。
调用栈
IBM i还管理每个线程或任务的调用堆栈。 这与等待记帐信息无关。 调用堆栈显示了已被调用的程序和过程，对于理解导致进入等待状态的逻辑流程非常有用。 持有人和服务员以及呼叫堆栈的组合提供了非常强大的功能来分析等待条件。
没有其他操作系统可以提供如此丰富的功能！
收集作业等待数据
收集服务和Job Watcher是IBM i上两种常用的性能数据收集机制，用于收集等待记帐信息。 收集服务默认情况下处于启用状态，并且始终收集作业等待数据。
当你需要收集工作观察者的性能数据工作观察者必须启动，它也会自动收集作业等待数据。 Job Watcher还收集持有人和服务员信息，以及（可选）调用堆栈和与SQL查询相关的数据。 如果要使用Job Watcher进行等待分析，则需要确保正在收集呼叫堆栈数据。 这可以通过在作业观察程序定义（ ADDJWDFN ）上具有“其他数据类别”（ ADLDTACGY ）参数来指定要收集的调用堆栈（ * CALLSTACK ）来实现。
分析作业等待数据
收集性能数据后，可以以图形方式分析数据。 从IBM i 6.1版本开始，IBM Navigator for i Web控制台具有调查数据功能，可通过浏览器界面以图形方式查看性能数据。 Performance Data Investigator文章回顾了此分析界面的功能。
查看作业等待数据的一个很好的起点是CPU利用率和等待概述。 此图表显示了分区的CPU利用率以及收集的等待信息。 下面显示的示例来自Collection Services数据，但Job Watcher数据也提供类似的图表。
图3：CPU利用率和等待概述示例
从图中可以看到，等待信息在图形中显示为堆叠的条形。 在此特定示例中，您可以看到调度的CPU时间，CPU排队时间，磁盘时间和操作系统争用时间都显示为感兴趣的区域。 存在锁争用时间，但是在大多数时间间隔中锁争用时间很少。 在此特定示例中，我们需要更好地了解是什么导致操作系统争用时间的一次高峰（尽管收集服务数据可能没有足够的细节来做到这一点；很可能需要Job Watcher数据才能达到根案例解决方案）以及造成磁盘时间的原因。 磁盘时间很可能是正常现象。
根据看到的等待数据的类型，可以选择适当的向下钻取选项以获取有关等待的更多信息，其中可以包括处于该等待状态的作业。 下图显示了此时可用于Collection Services数据的向下钻取选项。
图4：向下钻取选项提供了其他选项来查看等待数据
如果采用“磁盘等待概述”下钻选项，则可以看到绝大多数磁盘时间是由于页面错误引起的。 使用Collection Services数据进行进一步分析可以帮助我们确定与该磁盘故障时间相关的作业和线程。
图5：磁盘等待显示页面出现故障
使用Performance Data Investigator工具，您可以在许多不同的图表中查看等待信息。 并非所有图表都以相同的方式显示等待数据。 例如，使用Collection Services数据，“ CPU利用率和等待概述”图表显示了等待时段的子集。 有七个类别，一些存储桶被分组。 等待概述显示了15个选定的等待时段。 “按线程或任务的所有等待”提供了所有存储桶，但应在缩小的间隔内使用，以缩短响应时间。
使用Performance Data Investigator工具，您还可以类似于分析Collection Services数据的方式来分析Job Watcher数据。 Job Watcher是一个功能强大的性能工具，因为它使您可以收集和检查调用堆栈以确定正在运行的功能，该功能可帮助您弄清楚该功能为何会出现争用。 除了Job Watcher，您还可以查看谁拥有该资源。 假设已收集了调用栈，您还可以查看程序逻辑流程，了解线程如何进入特定的等待状态。
无论您看到的等待类型如何，您都还需要了解导致争用进行任何更改以缓解状况的原因。 通常，如果您看到任何类型的争用，则应查看调用堆栈以确定正在运行的功能，然后通过检查等待资源的持有者和服务员来辨别该功能为何发生争用。 。
分析Job Watcher数据具有更多与等待数据关联的图表和表格，以及在分析Collection Services数据时不可用的其他向下钻取选项。 下图显示了可以使用Job Watcher数据查看的提供的等待图的列表。
图6：使用Job Watcher数据的等待图
等待存储桶说明
等待存储桶说明
以下列表显示了IBM i 6.1和IBM i 7.1发行版中的等待存储区，以及每个存储区的高级描述。
- 在CPU上分配的时间
在CPU上分派的时间是一个特殊的时段，其中包含在CPU上分派线程或任务的时间。 这是任务调度程序关于线程或任务何时分配到虚拟处理器的视图，这与为线程或任务跟踪的CPU时间不同。 - CPU排队
CPU排队是一种等待状态，其中线程或任务已排队，等待在处理器上运行。 发生CPU排队的原因有多种。 最常见的情况是分区容量过大，并且工作量超过分区处理资源所能容纳的范围。 在这种情况下，工作将排队等待CPU。 工作负载上限延迟是可能导致CPU排队的另一个等待时间。 - 已预留
未使用保留的等待桶。
- 其他等待
其他等待是一个包罗万象的分组，在其中放置了不太适合其他组的等待点，因此，此存储桶没有一般性描述。 该存储桶中有多种等待条件，包括没有进一步唯一标识的通用等待。
- 磁盘页面故障
磁盘页面故障是与故障相关的等待点。 IBM i上的页面错误通常是正常的并且是预期的。 当必须将磁盘中的数据带入主存储器中但未显式读取时，就会发生页面错误。磁盘页面错误等待存储桶可以帮助您确定错误是否过多以及是什么原因导致的，这可能导致您评估是否需要采取措施降低故障率。 例如，您可能需要调整内存池大小以将常用数据保留在内存中。 有多种技术可用于优化将磁盘中的数据带入内存中，这不在本文的讨论范围之内。 - 磁盘无故障读取
磁盘非故障读取是显式同步读取，执行这些读取是为了将数据从磁盘带入主存储。 当执行同步读取操作时，应用程序将等待读取操作完成。 磁盘无故障读取等待存储区可以显示您的应用程序在从磁盘读取数据上花费了多少时间，并且可以帮助您评估该时间是否足够长，可以考虑应用程序更改（例如异步读取）。 - 磁盘空间使用争用
创建或扩展对象时，必须找到可用磁盘空间以满足请求，并且与此相关联的是某种程度的序列化。 通常，您应该很少会看到这种等待。 如果百分比很高，则通常意味着您的应用程序正在执行很高的对象创建/扩展/截断/删除操作。 （请注意，打开DB2文件会导致创建活动）。 磁盘空间请求的大小并不重要。 重要的是请求率。
- 磁盘操作开始争用
当磁盘操作启动由于在请求时正在进行的并发磁盘操作的执行率很高而延迟启动时，可能会发生磁盘操作启动争用 。 如果看到此等待类型，则可能需要查看发生的总体磁盘操作，以查看是否应消除明显的磁盘I / O低效率。 - 磁盘写入
磁盘写入是显式同步写入，用于将数据从主存储存储到磁盘。 当执行同步写操作时，应用程序等待写操作完成。 磁盘写入等待存储区可以显示您的应用程序在将数据写入磁盘上花费了多少时间，并且可以帮助您评估该时间是否足够长，可以考虑应用程序更改（例如异步写入）。 但是，此等待存储桶还包括与等待异步磁盘写入完成有关的等待。 - 磁盘其他
由于系统可能会等待磁盘操作的所有其他原因， 磁盘其他等待是全部捕获分组。 - 日志记录
就像存储桶名称所暗示的那样， 日志记录等待是与IBM®DB2®日志记录相关联的那些等待。 磁盘写入操作以写入日志。 这些写操作与常规磁盘写操作是分开的，使您可以分别了解日志写。 如果你看到杂志等待率很高，你可能需要查看该杂志的设计和应用程序使用的日志 。 - 信号量争用
信号量是UNIX / POSIX应用程序中通常使用的一种序列化机制。 信号量争用标识使用信号量时发生的等待。 信号量可以由应用程序，许可的程序产品以及操作系统使用。 - 互斥争用
互斥体是UNIX / POSIX应用程序中通常使用的一种序列化机制。 Mutext争用标识使用互斥对象时发生的等待。 互斥锁可由应用程序，许可的程序产品和操作系统使用。 - 机器级门序列化
机器级别的门序列化是一种内部序列化机制，用于许可的内部代码中，以序列化逻辑和访问数据结构。 如果门上存在锁定冲突，则显示为机器级别的门序列化。 门是一种内部锁定机制，但是您对某些功能（例如，日记帐）执行的操作可能会导致门被用来完成这些功能。 - 抓住竞争
抢占是一种内部序列化机制，用于在许可的内部代码中序列化对对象和数据结构的访问； 抓住是某种内部版本的锁。 当多个线程流过相同的占用/释放逻辑时，就会发生占用争用。 如果看到争用，则应查看调用堆栈以确定正在运行的功能，然后尝试辨别该功能为何发生争用。
- 数据库记录锁争用
当您的应用程序在数据库记录上发生锁定冲突时，就会发生数据库记录锁定争用 。 如果看到此锁争用，则应查看应用程序的DB记录锁定逻辑。 - 对象锁争用
发生对象锁定争用的原因多种多样-您的应用程序可以使用ALCOBJ命令显式锁定对象。 在对象上执行某些操作（例如创建或删除对象，移动对象或更改所有权）时，操作系统可能会隐式锁定对象。 - 不合格的等待
该存储桶是线程处于不合格等待状态的时间。 如果内存池的最大活动（MAXACT）参数太小，通常会发生不合格的等待。 - 主存储池超额使用
主存储池过量使用时，会发生主存储池过量使用。 磁盘读取或页面错误被延迟，以便找到可用的主存储页面框架。 - 经典Java用户（包括锁）
请参阅“经典Java虚拟机（JVM）”描述。
- 经典Java虚拟机（JVM）
与经典JVM相关的等待桶。 但是，在IBM i 7.1发行版中，不再支持Classic JVM，因此，这些等待桶实际上是保留的。 请注意，使用IBM Java技术（这是IBM i 7.1唯一受支持的JVM），等待时间实际上存储在可移植应用程序解决方案环境（PASE）存储桶中，因为该JVM是在PASE中实现的。
- 经典Java其他
请参阅“经典Java虚拟机（JVM）”描述。
- 套接字接受（空闲）
套接字接受（空闲）是一种正常的空闲等待，它在等待请求到达套接字时发生。 - 套接字传输
套接字传输是与通过套接字的应用程序编程接口（API）发送数据相关的等待。 请注意，许多TCP / IP应用程序服务器都使用套接字API。 - 套接字接收
套接字接收是与通过套接字的API接收数据相关的等待。 请注意，许多TCP / IP应用程序服务器都使用套接字的API。 - 插座其他
套接字的其他等待是由于I / O完成等待或使用select-socket API。 - IFS等待
IFS等待是由于集成文件系统（IFS）管道操作引起的等待。 - PASE
PASE等待是在便携式应用程序解决方案环境（PASE）中发生的那些等待。 PASE是IBMAIX®运行时环境，它允许AIX应用程序在IBM i上运行。 IBM Java JVM技术也运行在PASE中。 在PASE中可能运行着各种各样的应用程序，并且没有关于这些应用程序中等待行为的更多详细信息。 - 数据队列接收
数据队列接收只是那些等待数据队列对象的对象。 - 空闲/等待工作
空闲/等待工作是存储区，其中包含当应用程序处于预期等待状态时发生的正常等待条件。 如本文前面所述，空闲等待是正常的并且是预期的，因此，这些等待类型被分组到一个等待桶中。 通常，对正常等待条件的分析没有意思。 - 同步令牌争用
同步令牌是UNIX / POSIX应用程序中通常使用的一种序列化机制。 同步令牌争用标识使用同步令牌时发生的等待。 同步令牌可由应用程序，许可的程序产品以及操作系统使用。 - 异常竞争
异常争用是另一个笼统的问题，通常包含您通常不应该看到的意外或罕见的等待条件。
结论
IBM i等待计费功能是一种非常强大的功能，可用于更好地了解线程或任务的寿命，并且可用于性能故障排除和应用程序优化。
资源资源
- 我可以告诉您您为什么要等待，它提供了IBM i等待会计的高级概述。
- “作业等待”白皮书从更多的技术角度描述了等待计费，并包含了超出本文范围的有关等待计费的其他详细信息。 它还包含有关等待桶的描述。
- IBM i Performance Data Investigator是一个基于Web的图形分析工具，可用于分析等待数据。
- IBM iDoctor是基于客户端的图形分析工具，可用于分析等待数据。
- developerWorks站点上的IBM i Performance Tools提供了关于IBM i性能工具主题的许多有用信息和参考。
讨论
参加以下IBM i论坛：
翻译自: https://www.ibm.com/developerworks/ibmi/library/i-ibmi-wait-accounting/index.html