所有未过度使用系统基本上都是一样的，但是每一个过度使用的系统都会有不同的超载方式。如果一个项目的目标是最大化利用可用的计算资源，过度使用就不远了，但是过度使用发生的时候却很难定位问题所在。有些时候，即便存在问题也不会立刻显现出来。Johannes Weiner发布的pressure-stall information补丁可能会减轻系统管理员的负担，pressure-stall information补丁可以暴露更多系统真实使用状态信息。
有这个补丁的内核将会产生一个新的虚拟路径/proc/pressure，包含3个文件。第一个是cpu，描述系统对CPU的使用状态，读此文件会得到：
some avg10=2.04 avg60=0.75 avg300=0.40 total=157656722
avgX数据给出可执行线程由于CPU忙引起执行延迟超X秒(10秒、60秒、300秒)的百分比(avg10应该是含60和300的，avg60应该含300)。在每个CPU都只有1个可执行线程的系统中，所有数字都是0.如果数字出现显著增长，这意味着线程们由于CPU们的过载开始变的更慢。管理员可以利用这一信息来决定是容忍由于CPU承载量引起的延迟，还是做点什么使其更快一点。
这些延迟数据在给出系统繁忙度的方面与系统负载均值相似。系统负载均值是简单的给出正在等CPU的线程数(含等短I/O的线程)，这与CPU数量是相关的(要除CPU数)。而停顿信息却会追踪等待时间，不过追踪的时间范围比系统负载均值更短。
最后一个total是所有线程停顿的总时间(ms)，用来帮助侦测汇总数据不能体现的短延迟。一个CPU总是可用但是偶尔出现10ms短延迟，对于一些负载是可以接受的，但有些负载就不能，对于后一种，total计数可以侦测到这些短延迟的发生。
下一个文件是/proc/pressure/memory，可能就如你预期的一样，这是个提供线程由于内存压力产生延迟的时间，其提供的信息：
some avg10=70.24 avg60=68.52 avg300=69.91 total=3559632828
full avg10=57.59 avg60=58.06 avg300=60.38 total=3300487258
some行与CPU信息类似：追踪至少有一个线程可以执行(不必等待内存资源)的时间的百分比，特别是花费在swap内存进来的时间、从页缓存refaulting页面进来、执行直接回收，都可以以这种方式追踪到。并且它还会是系统由于缺内存进入颠簸的很好指标。
full行有一些不同：它追踪由于内存压力，没有线程能用CPU做实际工作的时间。如果所有线程都在等页I/O，CPU将会看起来idle，但并不是没有工作可做。如果这些线程正在整型内存回收，最后的结果可能是一样的：CPU忙，但并不是在做应该做的工作。如果full数据超过0太多，可以清晰的说明系统缺少支持当前工作负载的内存。
我们也注意区分出其他类型的页面短缺：一个刚启动的进程在其工作内容加载期间会经历很多缺页，但这些缺页并不表示系统负载。基于此原因，refaulted页面(基于内存压力被换出，又被换回的页面)才会被计入度量。尽管这样，还是存在一些误差，一个线程在执行不同的上下文可能需要不同系列的页，为了侦测到这种在不同工作上下文中的切换，补丁增加了对每个fault in的页是否加入过活跃链表(本质上就是用过不止一次)的追踪，只有被用过的页产生的延迟才会被加入统计。
最后一个文件在/proc/pressure/io，追踪等待I/O消耗的时间。这个数字在没有基线作为对比的时候很难用好。块设备子系统并不能追踪花费在争夺设备的额外时间，因此最终数据将不会直接与争夺设备相关。
在/proc/pressure文件夹下的文件最终系统整体的状态，在使用着控制组的系统中，同样会有与每个组相关的一系列文件(cpu.pressure,memory.pressure,io.pressure)。它们可以用来确定对每个控制组的资源闲置是否生效，他们同样使在繁忙的系统中确定引起延迟的线程更简单。
这一功能已经在脸书用了一段时间了，对优化系统资源、检查问题产生了很大帮助。Weiner说：“我们现在记录并图形化我们集群中的容器们的压力，并且可以在事后将延迟和吞吐量下降详细的链接到某种特定资源的短缺，然后修复工作设置和调度”。Android世界很明显也对此很有兴趣，Android的开发者们在寻找更好的方法来侦测系统性能丧失前的内存溢出的情况；Linus torvalds也明确表示这个思路看起来很有趣。现在还有些公开的问题就是CPU数据如何收集，不过可能很快就被干出来了。因此，十有八九，这个pressure-stall补丁将会很快进主线。
