停滞问题 - Linux中的冲突问题及其应对策略

与冲突问题对比，当遇到停滞问题时，首先要做的事情是什么呢?

　　Behman: 处理内核层面的停滞问题与处理应用软件层面的停滞是有着很大不同的。

　　如果你问的是关于应用软件层面。当冲突问题发生时，有着一种称为“信号处理”的特殊功能来调用处理各种各样的信息，例如内存中的信息，堆栈的跟踪反馈等。所以一般情况下，遇到冲突问题时，首要的问题就是收集、整理、分析这些数据。

　　而在停滞问题发生时，这种数据不会自动的收集，而这往往是一种人工的操作过程。收集停滞状态数据的两个关键点在于追踪输出结果以及堆栈的跟踪反馈。这种追踪输出结果的方式能够得出该进程作用情况的信息，因为它在一直的监视该进程;这些信息例如，该进程是否仍然在作用等等。而堆栈的跟踪反馈可以给出目前进程作用的源代码部分。这对于开发人员是非常重要的，这样以来他们就可以研究该进程停滞问题产生的原因。

　　对于冲突及停滞问题，其最主要的原因是什么呢?

　　Wilding: 对于冲突问题而言，我们可以把它的主要原因分为两种，一种是预防型的，另一种是错误处理型的。预防型冲突是内核或应用软件由于遇到了严峻的形势而产生冲突问题的情况。而软件意识到这种问题，并产生一种“自杀式”的方法以阻止错误的进一步发生，从而避免更加严重的问题出现。而对于错误处理型的冲突，它意味着内存中有着某些不合法的内容进入，几乎都是一些程序的错误。在这种情况下，硬件探测到这种应用软件，然后发送信号去阻止该软件的进程。

　　对于停滞问题而言，也一般存在着两种原因状况。一种是进程或线程等待资源的情况，这不一定能否解决。而其他的进程或线程约束着该资源(例如，上锁)，这样该进程或线程在等待时，其还占据着资源，从而其他进程或线程也只能等待。一个例子就是某个进程对占据的重要资源上锁，而其自身在漫无目的接收因特网的信息。第二中比较常见的原因就是一种“依赖回路式”的等待，在此两个或者多个进程在互相等待它方的资源，从而陷入“死锁”。这种情况的解决方法可以是释放一个锁，或者在某个空间中共享内存等。

　　在这些冲突以及停滞的情形之下，管理者们有哪些基本的调查研究规则可以应用呢?

　　Wilding: 一个最好的基本准则就是有组织的参加工作。很重要的一点就是把收集的数据有规则的放在一个明确的地点，这样将来能够很容易的找到。这对于那些同时遇到多个问题的情况尤为有用。

　　Behman: 另一个基本的准则就是要定量的收集数据，而不是定性的收集数据。例如，“昨天晚上6点，系统内存利用较低”，这是定性的观测。这在问题处理中的作用不大。关于该例子的定量的版本应该要收集并保存那些所有的输出的数据命令，以及其他一些相关的诊断命令。目的就是在于收集足够的数据，这样就可以尽可能的避免问题的再次发生;这就是“一次到位式”的方法，而不需要问题重复出现后，多次收集才能够得到比较完整的数据。