ibm aix 持续可用性dumpctrl

《ibm aix 持续可用性dumpctrl》由会员上传分享，免费在线阅读，更多相关内容在行业资料-天天文库。

1、IBMAIX持续可用性:第3部分多年以来，AIX操作系统一直包含由IBM技术支持的许多可靠性特性，现在通过应用更先进的技术进一步提高了AIX的可靠性。其中一些新特性包括对POWER6存储键的内核支持、并行更新、动态跟踪和增强的软件初次故障数据捕捉等等。　　错误检查　　Run-TimeErrorChecking　　Run-TimeErrorChecking（RTEC）让服务人员能够使用产品二进制代码中内置的调试功能。RTEC提供强大的初次故障数据捕捉和二次故障数据捕捉错误探测特性。　　基本的RTEC框架是在AIXV5.3TL3中

2、引入的，现在已经增加了更多的特性。RTEC特性包括ConsistencyChecker和XmallocDebug特性。这些特性一般可以通过errctrl命令调整。　　一些特性还有专门针对给定子系统的属性或命令，比如sodebug命令与新的套接字调试功能相关联。AIX出版物中描述了增强的套接字调试功能，可以在以下站点上找到：　　http://publib.boulder.ibm.com/infocenter/pserIEs/v5r3/index.jsp　　内核堆栈溢出探测　　从AIXV5.3TL5开始，内核提供用来探测堆栈溢出的

3、增强的逻辑。所有运行的AIX代码都维护一个称为堆栈的内存区，堆栈用来存储执行代码所需的数据。在代码运行时，堆栈会增长和收缩。堆栈可能增长到超过其最大的范围并覆盖其它数据。　　这些问题很难解决。AIXV5.3TL5引入了一个异步的运行时检查功能，用来检查特定的内核堆栈是否溢出。探测到溢出时的默认操作是在AIX错误日志中记录错误。堆栈溢出运行时错误检查特性由ml.stack_overflow组件控制。　　AIXV6.1改进了内核堆栈溢出探测，支持用同步溢出探测功能保护某些堆栈。另外，在启用恢复框架时，以前属于重大问题的某些内核堆栈

4、溢出现在是完全可恢复的。内核非执行（no-execute）探测　　非执行探测也是在AIXV5.3TL5中引入的，可以为不应该作为可执行代码的各种内核数据区设置这种保护。这个特性利用了页面级执行启用/禁用硬件特性。如果错误的设备驱动程序或内核代码的执行分支能够意外地进入这些页面，这个特性会马上探测到。以前，这种情况可能会导致崩溃，但尚未确定。　　这个改进会立即捕捉到执行无效地址的指令，使它们没有机会进一步损害或导致难以调试的次级故障，从而提高内核可靠性和可服务性。这个特性对于用户差不多是透明的，因为大多数受保护的数据区显然应该是

5、不可执行的。　　扩展的错误处理　　在2001年，IBM引入了一种结合使用系统固件和扩展错误处理（ExtendedErrorHandling，EEH）设备驱动程序的方法，可以从间歇性PCI总线错误中恢复。这种方法会恢复并重置适配器，由此开始对持久性PCI总线错误的系统恢复。出故障的设备不会立即失效，而是被“冻结”并重新启动，从而避免一次机器检查。POWER6技术把这个功能扩展到了PCIE总线错误。　　分页空间检验　　如果系统崩溃、挂起或其他症状的根源是数据损坏，那么很难找到问题的根源，这是因为症状出现的地方远离数据损坏的位置。分

6、页空间检验的设计目的是，检查从分页空间读入的数据是否与以前写出的数据匹配，从而改进FirstFailureDataCapture（FFDC）对分页空间数据损坏引起的问题的处理。　　当一个页面被换出（Pageout）时，会为页面中的数据计算校验和，并把校验和保存在与分页设备相关联的一个固定数组中。当页面被换回（Pagein）时，会为从分页空间读入的数据计算一个新的校验和，并与数组中的值进行比较。如果这两个值不匹配，内核就在日志中记录一个错误并终止（如果错误发生在系统内存中），或者向应用程序发送一个异常（如果错误发生在用户内存中）

7、。可以使用mkps和chps命令针对每个分页空间启用或禁用分页空间检验。这些命令的细节可以在对应的AIX手册页中找到。　　存储键　　大多数应用程序程序员都曾经遇到过意外的内存覆盖问题，也就是一段代码意外地写一个不属于该组件内存区域的内存位置。有一个新的硬件特性称为存储保护键（storageprotectionkey，本文中简称为存储键）。它可以帮助应用程序程序员找到这些意外的内存覆盖。　　内存覆盖和寻址错误属于最难诊断和处理的问题。随着软件大小和复杂性的增加，这个问题也会变得更复杂。在AIX上，许多软件组件共享一个大的全局地址

8、空间。这给应用程序和AIX内核带来了可服务性问题。　　根据设计，AIX64位内核大量使用一个大的地址空间。这对于避免在POWER处理器上执行高成本的MMU操作很重要。尽管这种设计对性能很有好处，但也增加了可靠性、可用性和可服务性（RAS）方面的困难。大型的64位应用程序（比如