我希望准确了解如何在仅托管 Tomcat 8 的 Red Hat 计算机上使用平均负载和 CPU 使用率。在网上查找后，我得出以下断言。这些断言正确吗？我非常确定第一个，因为它来自官方 Tomcat 文档。我对哪些进程可以处于不间断睡眠状态感到困惑。
1）Tomcat 使用线程来处理请求，使用的最大线程数由 Tomcat 配置定义（请参阅Tomcat 文档）
2）Oracle JVM 仅从 JRE 1.3 开始支持本机线程（请参阅JVM 和线程我没有找到关于这一点的 Oracle 参考）
3）Linux 的运行队列以相同的方式包含进程和线程（id 本机线程）（参见Linux 平均负载：解开谜团和维基百科）
4）平均负载提供运行队列中进程/线程的平均数量（参见Linux 杂志）
5) 在仅运行 Tomcat 的 Linux 机器上，平均负载提供的请求数几乎是平均数。
6）在 Linux 上，平均负载计算处于运行、可运行和不可中断睡眠状态的进程/线程数（参见Linux 杂志）
7）处于不可中断睡眠状态的进程/线程正在等待磁盘 I/O、不可中断锁、网络 I/O（参见Redhat 文档包括网络 I/O 和Linux 平均负载：解开谜团不包括网络 I/0 ）
第 7 点与参考文献不一致，请参阅Linux 杂志这句话的意思是“事实上，测量的正是 CPU 负载，因为平均负载不包括任何等待 I/O、网络、数据库或任何其他不要求 CPU 的进程或线程。”。
我理解如果一个进程读取交换，它处于不间断睡眠状态，但如果它读取内部磁盘、nfs 文件夹或 SAN 托架上的文件，它是否处于不间断睡眠状态？Red hat 文档列出了网络，如果一个进程请求网络上的资源，它是否处于不间断睡眠状态？
答案1
1）是的：Tomcat使用线程来处理请求。
2）是的：Oracle JVM 和 OpenJDK JVM 仅从 JRE 1.3 开始支持本机线程
3）是的：Linux 的运行队列以相同的方式包含进程和线程（id 本机线程）
4）是：平均负载提供运行队列中进程/线程的平均数量
5）不适用
6）是：在 Linux 上，平均负载统计处于运行、可运行和不可中断睡眠状态的进程/线程
7) 这需要重新表述。你似乎知道交换空间是如何工作的。所以重点是：I/O 正常文件通常使用相同的机制（不是相似 - 实际上是相同）。这称为mmap。当您的应用程序想要写入文件时，abc.txt它只会更改预定义内存地址的字节。内存页面（4096 字节）被标记为dirty。很快它会被后台守护进程写入文件系统（而不是交换空间）。当应用程序只是打开文件进行读取时，它会获取最初没有内存页面的内存地址。当它实际访问那里的内存时，内核会读取文件的页面并使其出现在那里。这就是 Linux 中通用磁盘缓存的工作方式 - 它非常像分页，仅此而已。
现在网络Linux 有几种方法可以山文件系统不驻留在本地 SAS/SATA/FC 磁盘上，但实际上通过网络进行通信（例如 NFS 或 CIFS）。因此，分页a.txt实际上会导致数据包通过网络传输。在这种特定情况下，您的进程没有套接字，只有其自身地址空间中的 mmapped 地址。它所做的一切都是在内存位置之间移动字节。
不间断睡眠被定义为等待该机制 - 无论文件系统是从磁盘还是从网络挂载。假设我们正在读取并等待下一页 - 该进程需要存在并且需要拥有内存，因为内存必须准备好接收从磁盘读取的字节（想想：DMA 正在进行中）。这就是为什么它不管你怎么做都会留下来 kill -9。
并且使用进程拥有的套接字完成的正常网络流量是标准睡眠，这不计入平均负载中。
进程也可以“以老方法”读取磁盘，而无需mmap，这也是标准睡眠。这种情况相当罕见。
答案2
在我看来，平均负载的“精确”并不是一个有用的功能。它是一种算法，但有点随意地汇总了缓慢的系统的感觉。来自sched/loadavg.c：
该文件包含计算全局 loadavg 数字所需的魔法位。这是一个愚蠢的数字，但人们认为它很重要。
尤其是那篇 Linux Journal 文章将平均负载称为中央处理器负载指标。自 1993 年左右添加 TASK_UNINTERRUPTIBLE 以来，CPU 关闭状态（例如 I/O 或某些锁定）。这使得它更像是系统负载指标。（这是 Linux 特有的。）
你引用的 Gregg 的帖子，Linux 平均负载：解开谜团没有完整的清单，因为
如今，在Linux 4.12中，有近400条代码路径设置了TASK_UNINTERRUPTIBLE，其中包括一些锁原语。
而不是一个完整的列表，它显示了如何通过非 CPU 火焰图测量内核不间断性。这有助于理解为什么即使 CPU 利用率较低，您的工作负载的平均负载也可能很高。
良好的性能监控描述应用程序用户对完整请求的响应时间。
找到响应时间与平均负载之间的任何关联。4 CPU 系统上的 6 负载可能是工作负载性能下降的征兆。（这个数字是我编造的，请查看您的数据。）
当负载较高时，确认应用程序响应缓慢，然后深入研究系统的每个资源以找出原因。