Body

Dawn May 原文链接 i Can … Tell You Why You’re Waiting

IBM i 系统的等待统计（Wait accounting）技术是一项专利技术，它能告诉用户一个线程或任务在不使用CPU时在等待什么。这应该是IBM i 系统的独有功能，因为罗切斯特实验室 (Rochester, Minn) 独立开发了 i 系统的所有层次。

等待统计技术的详细性能分析功能非常强大。这个组件（entry)主要关注于线程的等待——为何线程处于等待状态，如何利用等待统计来解决性能问题，或简便易行地提高应用程序的性能。

让我们先来熟悉一些术语。大多数的人都对“作业（JOB）”这个概念并不陌生。每一个作业至少有一个线程，同样也可以有多个线程。每一个线程通过一个LIC（Licensed Internal Code）任务表现出来，但需要说明一下的是，LIC任务即便脱离了IBM i 的线程级结构也可以存在。LIC任务通常外部不可见，除非使用IBM i 系统的性能工具或服务工具才能见到它。等待统计概念对线程和任务都适用；因此，当谈到一个可执行的工作（Work）时，“线程（thread）”和“任务（task）”这两个词通常会被用到。

一个线程或任务有两个基本状态。线程或任务在处理器上运行——运行态；或者正在等待处理器——等待态。等待的三种情形是：

1.                 线程或任务已经准备好运行了，但是需要等待处理器。这是一种特殊的等待状态，通常是指CPU排队状态；CPU排队状态的意思是线程或任务进入队列，等待分配CPU运行。一个导致CPU排队等待发生的原因是：分区已经过载了，但仍有超过它处理能力的工作需要处理。逻辑分区（Logical partitioning）和多线程同步同样会导致CPU排队等待。这些都是相当复杂的课题，《作业监控白皮书（Job Watcher whitepaper）》中涵盖了这方面的内容。

2.                 空等待（Idle waits）。空等待是正常的、预期的一种等待情况。空等待发生的情况有：当线程正在等待用户输入、网络回应或另一个应用程序的响应。在收到回应前，线程没有任何工作可做。

3.                 阻塞等待（Blocked waits）。串行化机制对共享资源的同步访问控制导致了阻塞等待的发生。阻塞等待有可能是正常的或预期的——例如，对表中一行更新使用串行化访问控制，磁盘I/O操作，或通信I/O操作。但是，阻塞等待同样也可能是非正常的，这时，对付这些非预期的阻塞就是等待统计可以大展身手的地方。

大家可以想象一下线程或任务的生存周期，以图形的方式，把它分成运行时间和等待时间。这种概略的图形化描述被称作运行-等待时间拍（run-wait time signature）。 

通常，改善应用程序性能的重点在于使这个应用程序尽可能有效的利用CPU。而对于拥有等待统计的IBM i 系统而言，我们可以查看到等待的时间长短，并且弄清楚是什么导致了这个等待的发生。如果导致等待的因素可以被减少或者消除，则应用程序整体的性能必然会被提高。

在IBM i 系统中，几乎所有导致等待发生的情况都已经被发现并且列举了出来，换句话说，每种等待状况都对应了一个数字。6.1版本中包含了有268个各异的等待状况！持续跟踪每个进程或任务的这么多各异的等待状况会消耗太多的存储空间，因此IBM采用了分组的方法来解决这个问题。每个等待状况都会被分配到32组中的一组中。当线程或任务进入或退出等待时，任务分发组件会将其等待状况映射到相应的组中。

如果使用等待统计来分析运行-等待时间拍，我们就可以标识出是这样一些因素——磁盘读操作时间、磁盘写操作时间、记录锁操作时间、日志操作时间——构成了线程和任务的等待时间：

当我们了解了等待涉及的各个类型后，就可以通过问自己一些问题来定位产生等待的原因了。比如在上述情况下，我们可能会问：

1.                 磁盘的读操作会不会导致了页错误，从而产生了等待？如果是的话，我的缓冲池的大小是否合适？

2.                 什么样的程序引起了磁盘的读写？有没有不必要的I/O操作？可否减少或消除它们？或者可不可以把它们变成异步执行？

3.                 我设置的记录锁策略是否是最佳的？或者我是不是加了不必要的锁？

4.                 什么样的文件设置了记录作业日志？这些日志是否都是必须的？它们有没有采用最佳的配置方案？

如果为应用程序进行了等待分析，我们就能看到许多这些等待组的表象。弄明白应用程序在做什么，它为什么在这些情形下会处于等待状态，能帮助我们减少或消除不必要的等待。

使用者(Holder)与等待者(Waiter)

IBM i 系统不仅会持续跟踪等待资源的线程或任务，也会跟踪分配了资源的线程和任务。这是个非常强大的功能。使用者（Holder）是指正在使用串行化资源的进程或任务。等待者（Waiter）是指等待使用串行化资源的线程或任务。

调用栈

IBM i 系统同样管理着每个进程或任务的调用栈。调用栈和等待统计信息是相互独立的。调用栈显示的是被调用的程序或函数信息，这对于弄清楚等待状况是十分有用的；因为调用栈给出了一个逻辑大纲，从这个大纲中可以看出程序要么是正使用某个资源，要么是在请求某个资源。使用者、等待者、和调用栈的组合，提供了一个非常强大的功能可以用来分析等待状况。其他的操作系统没有一个能够提供如此丰富的功能。

收集并分析数据

数据收集服务（Collection Services）与作业监视器（Job Watcher）是两种性能数据获取机制，它们收集等待统计信息。作业监视器同样也收集使用者、等待者，以及调用栈信息。性能数据一旦被采集到，我们就可以使用图形化方式分析它们了。在IBM i 的6.1版本中，“IBM Systems Director Navigator Web console”可以看到Performance tasks；数据调查功能被用于通过浏览器接口图形化展示等待数据信息。用户同样还可以使用iDoctor图形界面来查看等待数据信息。

新的红皮书《IBM i 端到端性能管理》涵盖了上面提到的数据调查功能与等待统计技术，对其有更详尽的描述。