大多数情况下，按照报错可以很快找到原因，但总有例外。一些错误消息或日志只会让我们走错路。且看这些案件最后是如何处理的……案件一：为了省事，惹了大麻烦。生产中心有几套VIOS环境，已经正常运行了1-2年。今天发现有2套VIOS环境在进行健康检查。发现执行命令的时候hang不动，内存不够。“0403-031forkfunction失败。可用内存不足。”好奇怪，谁用的内存，vios的就没问题。都是这样，重启vios分区。重启后vios成功登录，健康检查没有问题。但是，我用nmon查看内存占用，分配了4G，用了1G多，慢慢的，看到内存占用越来越大了。过一会4G就用完了，重启其他vios分区，连分页空间都用完了。顿时糊涂了。到底发生了什么？生产中心有几套VIOS环境，已经正常运行了1-2年。突然出现这种问题，首先想到的就是改变。整理了最近的改动。最近新部署了PowerVC，给VIOS打了补丁升级了。将VIOS2.1升级到VIOS2.2.3。首先重启vios分区，在内存用完之前快速查看那个进程使用的内存。第一个是vio_daemon。观察了一会儿，发现内存有一段时间被他占用了。二、罪魁祸首找到了，vio_daemon到底是做什么的，问IBM800，IBM回复让我收集系统信息。ioslevel/etc/security/limits的输出反馈后，IBM告诉我遇到了bugvios版本，/etc/security/limitsstack=-1完全符合这个bug的特征。其实这个bug是可以避免的。当我们大多数人实施AIX时，很容易更改/etc/security/limits。到-1。大多数情况下是没有问题的，只是在这个版本下很容易碰到这个问题。默认值：fsize=-1core=-1cpu=-1data=-1rss=-1stack=-1nofiles=-1问题可能是由于VIOS2.2.3.0到2.2.3.3中的一个已知问题，其中vio_daemon具有IV64508已修复2.2.3.4的内存泄漏，或者可能是由于不正确的VIOS设置。答案要检查您的VIOS级别，作为padmin，运行：$ioslevel如果您的VIOS级别是2.2.3.4或更高，问题可能是由于VIO在/etc/security/limits中的系统设置不正确。如果“堆栈”大小设置为“无限制”(stack=-1)，这会暴露一个条件，允许系统根据需要固定尽可能多的堆栈，从而导致vio_daemon消耗大量内存。$oem_setup_envvi/etc/security/limits->checkthedefaultstanzadefault:fsize=-1core=-1cpu=-1data=-1rss=-1stack=-1nofiles=-1在某些情况下，在VIOS更新到2.2.3后会注意到vio_daemon消耗高内存的问题。X。但是，aVIOS更新不会更改这些设置配件。强烈建议不要修改这些默认值，因为这样做会导致不可预测的结果。以下是默认值的示例：default:fsize=2097151core=2097151cpu=-1data=262144rss=65536stack=65536nofiles=2000要更正问题，请将设置改回“默认”值。然后尽早重新引导VIOS。案例2：安装AIX，但假装存在信任危机。某制造用户，一个新项目急需上线，于是维护厂商的工程师赶紧准备了一个AIX资源。安装AIX系统ma工程师应该不陌生，但是这次安装了好几次，AIX系统就是进不去。对AIX版本存疑，结果两次失败。3、对硬件的怀疑。输入asm没有报错。首先，让我谈谈用户设备的背景信息。Power710设备特点：定位应用服务器，价格便宜，即不需要HMC管理，使用安装在串口上的IVM来部署和管理虚拟化环境。这个710以前是用来做应用服务器的。IVM环境已经部署好串口，本次重装需要注意串口输出问题。因此，必须进行如下配置才能成功进入系统。第一步：进入保养模式。如果进入MaintenanceMode步骤，则省略第二步：#exportTERM=vt100#smitchtty红色标出的两行，添加clocal.syncsyncsyncreboot后，就可以系统正常运行了。案例三：安装AIX时报这个错。新手老手都没见过。我相信社区中的大多数人都安装了AIX数十次甚至数百次。但是今天安装AIX的时候报这个错。新手老手都没见过。安装AIX到此为止。其实我也经过大家多方排查，最后整理了一下，发现是AIX安装的问题，排除了硬件介质的问题。估计是配置问题，按照这个思路。首先，既然是配置，那就去profile文件吧。看。如果你不检查，你不知道。检查问题后，您会发现它。有人会说，你犯了这么低级的错误。错了，是PowerVC的错，我没有说清楚自己的背景。这是PowerVC部署aix时出现的问题。第二，问题找到了，为什么会出现问题？deploymentpartitionprofile配置是在Powervc中设置的，那就去Powervc找答案吧。问题就出在这里。PowerVC管理着很多主机，每台主机的配置都不一样。为了省事，配置了一个varycomputingtemplate，最大cpu配置设置为32。实际部署AIX时，我选择了低配置的powerserver。CPU配置不是32，只有20，结果被PowerVC配置为25.6。有这样的问题。反思这个问题，PowerVC，规划配置模板，配置尽可能多的计算模板来匹配服务器。避免此类问题。这个问题还有第二种解决方法：在kdb模式下输入f可以查看堆栈信息，也可以找到profile配置信息。Case4:执行lsrep，奇怪报Insufficientmemory执行lsrep，奇怪报Insufficientmemory查vios分区内存占用好像和内存没有关系。首先检查其他vios是否有这个问题，发现没有出现这个现象。比较vios版本及其lsrep输出，找到vios版本。尽管如此，唯一的区别是有问题的vios/var/vio/VMLibrary没有iso。将几个AIXiso转移到有问题的vios/var/vio/VMLibrary后，再次执行lsrep，成功。Case5：PowerHA向Oracle新增表空间，遇到内存croedump通过PowerHA向Oracle新增表空间。使用C-SPOC在线添加LV，开始添加到Datavg，很顺利，添加10很成功，继续添加新的lv后，没想到报错。内存croedump.1，是不是内存不够？查了一下我有点紧张hostA:hostB:2，仔细看了Powerha日志，没有什么有价值的信息。难道真的是内存不够用造成的。3、由于需要给其他vg添加lv，所以又尝试给其他vg添加lv。有效。这个问题从内存报错开始就很容易给人一种内存不足的错觉。实际环境确实是内存利用率高，但是最终定位的问题并不是内存不足导致的。首先，前几个lvs加的很顺利，后几个失败了，然后其他vg的lvs也加成功了。这时候我开始怀疑是不是遇到了bug。第二，一般的裸奔powerha更容易遇到bug。查看powerha补丁情况。果然，基本就是裸奔的Powerha环境。遇到错误并不奇怪。三、既然怀疑是bug，那就找点有说服力的吧。IV36992:CLPASSWDREMOTECOREDUMPSDUETOMEMORYFAULTAfixisavailableObtainthefixforthisAPAR.错误描述clpasswdremoteutilityiscoredumpingduetosegmentationfault.当用户在/etc/passwdin集群中的节点之一丢失时会出现问题。cspoc.log将记录以下内容：[==========C_SPOCCOMMANDLINE==========]/usr/es/sbin/cluster/sbin/cl_chpasswd-cspoc-f-r-cspoc-grg1test3hacmp13：成功：/usr/es/sbin/cluster/etc/clpasswd/usr_bin_passwd.origtest3hacmp14：失败：evalclpasswdremote-utest3-p'raCYOSMwhoJU。-f2-l0hacmp14:cexec[54]:3735594Memoryfault(coredump)hacmp14:RETURN_CODE=139hacmp14:cl_rshhadexitcode=139,seecspoc.logand/orclcomd.logformoreinformation错误报告将记录核心转储错误具有以下堆栈跟踪：main94main88__start6C以下症状code也被记录：PIDS/5765E6200LVLS/520PCSS/SPI2FLDS/clpasswdrSIG/11FLDS/mainVALU/94FLDS/__startLocalfixEnsuretheuserexistsin/etc/passwdfileinallthenodesinthecluster.ProblemsummaryIf用户不是使用cspoc创建的，因此它存在于集群中的所有节点上，那么如果您尝试使用cspoc在集群范围内更改该用户的密码，clpasswordremote将在未配置用户的节点上进行核心转储。smit输出将如下所示:Changingpasswordfor"tstuser"hack2:cexec54:8781858Memoryfault(coredump)问题结论在clpasswdremote中添加了一个检查，以避免尝试在未定义用户的节点上更改密码。案例六：V7000紧急状态，“emergency”我用PowerVC部署AIX分区，部署失败。报告了一堆莫名其妙的错误。奇怪的是前几天部署还正常。今天无法查看PowerVC服务是否正常。登录HMC查看是否有partitionprofilecreated，发现No。白白返回，返回PowerVC继续排查，到了内存才发现蛛丝马迹，不过看着挺吓人的。V7000存储卷的健康状态已更改为严重。登录V7000查看，发现V7000没有问题。这很奇怪。实际上PowerVC中的V7000状态告警并不能反映V7000的真实状态，而是通信问题导致的。至于通讯问题，后来问了网络人。在我的部署过程中，网络正在发生变化，因此PowerVC无法向V7000发送命令，PowerVC将V7000标记为紧急。案例7：先入为主的异常故障处理！！P740服务器通过SAN交换机连接到DS4700存储。硬件维修商更换蓄电池（A对照）后，服务中断。我司负责数据库和系统维护，客户打电话到现场检查问题。经过一番排查，发现A控制器上的所有LUN都找不到。发现问题后，我们开始排查问题。我问过硬件维修商在换电池的时候有没有碰别的东西，得到了很准确的回答。我们只是更换了电池，没有做任何其他事情。然后连接存储SM，将所有的LUN从A切换到B，就可以看到系统中所有的磁盘了。OK，问题出在A上，在SM中看到的存储没有报错，没有问题。继续把原来的LUN从A切换到A，控制到一半，系统又找不到了。。。我开始删除所有硬盘，然后重新识别。。。还是没有工作……忙了两三个小时，客户一直说什么时候可以，硬件维修商坐在他旁边的人好像没事……我去机房拿看一眼，我也得看一眼。客户带我们走出机房，再看主机和HBA卡连接线，一切都那么美好。然后我看到光缆从存储A控件里出来了……你他妈插错了！！！客户用异样的眼光看着硬件维修商……处理问题不要先入为主，一定要自己确认一切，以免出错！！！案例8：varyonvg错误分析及处理（LVM相关）AIX操作系统计划升级操作系统版本时，发现VG的varyon和varyoff命令有警告信息。经分析，这只是警告信息，不影响使用，具体告警信息如下：系统环境：AIX5.3TL12SP7首先分析一下当时的报错内容。从运行内容可以看出，在执行varyoffvg命令时，底层调用lqueryvg子命令报错，而lqueryvg是一个查询类型的命令，该命令的返回内容表示VG的定义信息与VGDA的描述不一致。对于此类告警信息，当操作系统重启后，会自动更新VG的相关信息，进行自动修正。当时的计划是升级操作系统，修改磁盘的reserve_policy属性，所以打了补丁后直接重启，这个过程中已经更新了VG信息。然后分析当时的操作步骤和LVM日志，验证对应关系。当时的操作记录如下。根据运行日志，在重启操作系统之前进行了2次varyoffvg和1次varyonvg操作：分析当时的LVM日志，可以看出第一次varyoffvg错误时读取的VG信息不一致。当前消息出现在第一个varyonvg处。同样的信息也出现在第二个varyoffvg期间。以上信息为操作系统重启前的信息。下面是对操作系统重启后LVM相关信息的分析。从日志中可以看出，当操作系统重启时，varyon中VG的返回值为0，说明重启进程更新了VG。信息。综上所述，重启操作系统后，VG信息已经自动更新，告警信息自动消除。治疗建议：继续监测。Case9：执行lspvlsvg-o等命令时，报错。odm库修复方法在一个公司有4台机器。执行lspvlsvg-o等命令报错如下：使用strings命令查看CuAt文件，发现前两行不正常。确定是系统ODM库损坏。查看ODM库文件的修改时间，某月某日10点20分左右，多个ODM库文件被修改。可能损坏的文件包括CuAt、CuAt.vc和CuDvdr三个文件。尝试修复ODM库文件：方法一：1、用UE打开CuAt文件，发现文件头信息被篡改。与正常机器的CuAt相比，损坏的文件显示文件的前7行与其他CuAt文件不一致。.2、如果要手动修复文件，可以按照正常的CuAt文件修改这七行信息即可。对于普通的CuAt文件，CuAt的条目数应该是一个32位的longint变量，第一行是4,5,6，第7列的值表示CuAt文件中已经存在的条目数，odmget会取值时参考这个值的大小，即如果值为1，则只取一条记录。因此，如果要修复该文件，您需要知道CuAt的确切条目数。如果将其设置为较大的值，则在执行odmgetCuAt后，多余的条目将显示为空条目，如下所示。根据这个方法，可以判断出准确的条目个数，然后转换成十六进制写入相应的位置。方法二：1、对于HA环境，每次验证成功后，HA都会备份HA使用的odm库文件，位于/var/hacmp/odmcache/
