AIX 5.2 或 5.3为什么要将系统dump device和hd6分开呢？

突然想不明白了。两个和在一起不是很好吗？

附：为什么有些AIX系统中有lg_dumplv 逻辑卷？

环境产品,pSeries, p5, RS600
软件版本, AIX5.2, AIX5.3

问题安装完新AIX系统后，细心的用户会发现，有的AIX 中有 lg_dumplv 逻辑卷，有的则没有。为什么会这样，它有什么作用，是按照什么规则来创建该逻辑卷的？

解答在AIX 系统中的lg_dumplv 逻辑卷是用于存放系统dump 的区域。在安装系统时是否创建该逻辑卷与服务器的内存配置有关。

若服务器的内存小于4GB时, 那么在安装 AIX 5.2 或 5.3时，系统就不会自动创建它。而缺省将系统dump 存放在hd6上。
当服务器的内存大于4GB时，在安装AIX时，就会为系统 dump 创建一专用区域，该逻辑卷名就是 lg_dumplv. 其缺省大小是按以下规则分配的：
. 4GB < = 服务器的内存〈 12GB lg_dump 的大小为 1GB
. 12GB < = 服务器的内存〈 24GB lg_dump 的大小为 2GB
. 24GB < = 服务器的内存〈 48GB lg_dump 的大小为 3GB
. 48GB < = 服务器的内存 lg_dump 的大小为 4GB

作者: beginner-bj 发布时间: 2005-12-19

从我接触AIX开始，就没见过hd7。不知道哪位玩AIX时间长的，能讲讲为什么当初hd7消失，和现在lg_dumplv重又出现？
另外，不知道IBM干嘛要起个新名叫lg_dumplv，叫hd7不就好了？

作者: beginner-bj 发布时间: 2005-12-19

■内存小于4GB的时候，paging space的空间划分原则基本上能够保证paging space不小于内存大小，因此当然能够容纳系统DUMP，这样，paging space无需为系统DUMP的考虑而占用更多空间
■当内存大于4GB的时候，paging space往往不用按照大于等于内存的原则来划分，而且内存越大，这个差距很可能越明显，而且，大内存情况下，很多客户随着机器上应用规模的扩张或应用数量的增加，paging space是逐步增加的，而且这个增加很多时候并非体现在hd6上，而是新建paging space空间，以便分散硬盘负载。这些都会造成内存大大超过hd6，这样hd6放不下系统DUMP的概率很高

以上这些限制，如果不用专门的存放系统DUMP的设备，而是和hd6混用，必然造成hd6为满足系统DUMP的需要而不必要的大。可能你会有这样的疑问：hd6扩大，和减小hd6，增加一个lg_dumplv，总体空间占用并无节省啊？别忘了，大内存的机器往往是业务关键设备，一般rootvg要做镜像的，hd6必须镜像，但dump设备没必要（做了镜像也无用），这空间可就节省很多个G了

[ 本帖最后由 larryh 于 2005-12-20 08:42 编辑 ]

作者: larryh 发布时间: 2005-12-20

学习一下

作者: brucewoo 发布时间: 2005-12-20

谢谢larryh的回复。

这样看来在内存>4GB的情况下，使用lg_dumplv是为了节省硬盘空间。而且这里隐含了一个前提，dump device的尺寸要比paging space的尺寸要大很多，如果这个前提不成立，那么我想就不存在节省硬盘空间这种说法了。

对lg_dumplv的大小我还有疑问。
我这有台实际的AIX5.3，是默认安装的，没有人为调整。
Memory Size: 7808 MB
Total Paging Space: 512MB （就是hd6，做了mirror）
lg_dumplv Size: 1024 MB （没做mirror）

myaix#/> sysdumpdev -l
primary             /dev/lg_dumplv
secondary          /dev/sysdumpnull
copy directory    /var/adm/ras
forced copy flag    TRUE
always allow dump FALSE
dump compression    ON
myaix#/> sysdumpdev -e
Estimated dump size in bytes: 237397606
myaix#/> sysdumpdev -c
myaix#/> sysdumpdev -e
Estimated dump size in bytes: 1186988032
myaix#/> sysdumpdev -C
myaix#/> sysdumpdev -e
Estimated dump size in bytes: 237607321
myaix#/> lsps -a
Page Space    Physical Volume Volume Group Size %Used Active  Auto  Type
hd6          hdisk3          rootvg       512MB    5 yes yes lv
myaix#/> svmon
            size    inuse    free       pin virtual
memory    1998848 1552157    446691    191965    829920
pg space    131072    5315

            work    pers    clnt
pin       191704       0       261
in use    829920       0    722237
myaix#/>

这里可以看到在不压缩的情况下Estimated dump size in bytes: 1186988032 （1187M），即不是7808 MB，也不是7808 MB+512MB或7808 MB+512MB*5%

在压缩的情况下Estimated dump size in bytes: 237397606 （237M），这个比hd6还小，显然如果这台实际的机器用hd6来做dump device，可以删掉lg_dumplv，节省了1024 MB的空间。

作者: beginner-bj 发布时间: 2005-12-20

原帖由 beginner-bj 于 2005-12-19 22:32 发表
从我接触AIX开始，就没见过hd7。不知道哪位玩AIX时间长的，能讲讲为什么当初hd7消失，和现在lg_dumplv重又出现？
另外，不知道IBM干嘛要起个新名叫lg_dumplv，叫hd7不就好了？

In AIX 3.2, the default primary dump device is /dev/hd7. This is a logical volume dedicated for system dumps.

对于这个hd7起名字这事情，就是一个标识而已，应该没啥典故了

作者: workaholic 发布时间: 2005-12-20

楼主的这个是你的特例，可以删除lg_dumplv，但是将来你要经常观察sysdumpdev -e，一旦有超出就要扩大hd6或者建DUMP设备，除非可以确认软件环境不再变化

IBM设计的时候当然应该按照最reasonable的方法去做，而不是专门考虑中国用户这种经常没事买个大内存实际上用不上的情况

作者: larryh 发布时间: 2005-12-20

larry的意思是否这个sysdumpdev -e的结果会因为软件的使用而增大。

作者: 炸鸡发布时间: 2005-12-20

原帖由 workaholic 于 2005-12-20 10:37 发表

In AIX 3.2, the default primary dump device is /dev/hd7. This is a logical volume dedicated for system dumps.

对于这个hd7起名字这事情，就是一个标识而已，应该没啥典故了

我想当初hd7和hd6合并，应该是有原因的，现在dump device和 paging space分开也是有原因。我原来也认为这两件事情的原因都是为了节省硬盘空间。但现在仔细想了下，发现好象不太对。实在是越想越糊涂了。

作者: beginner-bj 发布时间: 2005-12-20

原帖由 larryh 于 2005-12-20 10:48 发表
楼主的这个是你的特例，可以删除lg_dumplv，但是将来你要经常观察sysdumpdev -e，一旦有超出就要扩大hd6或者建DUMP设备，除非可以确认软件环境不再变化

IBM设计的时候当然应该按照最reasonable的方法去做，而不 ...

larryh叫我beginner好了。

这里实际上是两个问题：
1、dump device的大小到底由什么决定？
看一下缺省规则：
. 4GB < = 服务器的内存〈 12GB lg_dump 的大小为 1GB
这里有个问题，dump device的大小为什么只有1GB？为什么只有内存的1/4至1/12？

我的例子里，内存是8G，svmon看到已用内存是6G；lsps看到paging space用了25M。

在不压缩的情况下sysdumpdev -e 看到是1.2G，这1.2G的空间要装什么东西呢？难道只装已用6G内存的一部分吗？

2、实际所需的dump device的大小会不会比hd6要小？
但不管怎样，dump device的大小肯定是要比物理内存小很多了。至于大多数情况下，sysdumpdev -e看到所需尺寸会不会比hd6要小，这个不好罔下定论，但我的例子是这样的。

作者: beginner-bj 发布时间: 2005-12-20

beginner-bj并非beginner。

我想分开和结合都是因为成本效益，要考虑当时的内存技术，内存和硬盘的价格比例。总之，我觉得现在还是分开的好。

作者: 炸鸡发布时间: 2005-12-20

我当初注册ID时，注册beginner不成功啊，没办法只要加了个-bj。

作者: beginner-bj 发布时间: 2005-12-20

原帖由 beginner-bj 于 2005-12-20 11:28 发表

larryh叫我beginner好了。

这里实际上是两个问题：
1、dump device的大小到底由什么决定？
看一下缺省规则：
. 4GB < = 服务器的内存〈 12GB lg_dump 的大小为 1GB
这里有个问题，dump device的大小 ...

1、DUMP只存放与系统DUMP可能有关的区域，那些用户进程的私有区域无论怎么乱搞都不可能造成系统DUMP的，所以不会保存
2、实际所需的dump device的大小会不会比hd6要小？
很有可能。但是也见过一些超过1GB的。AIX不能保证第三方软件的体积，而第三方软件为了实现一些功能都有可能往内核上加东西，第三方内核扩展是典型，还有第三方驱动。如果一台机器比其他机器安装的第三方系统软件明显多，连接的第三方外设明显多，你会发现其DUMP预计空间也大得多。

还想到一点：独立dump设备，即使发生DUMP后重启，没有足够的空间存放dump copy或者被用户选择放弃copy，都能够事后从DUMP设备上获取DUMP来分析，如果放到hd6，只好丢弃没有任何办法可以再分析了

作者: larryh 发布时间: 2005-12-20

beginner-bj技术其实很厉害的。

搬个板凳学习

作者: workaholic 发布时间: 2005-12-20

原帖由 larryh 于 2005-12-20 12:37 发表

1、DUMP只存放与系统DUMP可能有关的区域，那些用户进程的私有区域无论怎么乱搞都不可能造成系统DUMP的，所以不会保存
2、实际所需的dump device的大小会不会比hd6要小？
很有可能。但是也见过一些超过1GB的 ...

再次感谢larry。老大的话，我还没有完全理解，还需要一些时间消化消化。这个问题先搁置在这，以后等我想明白了再说。

另外，还有一个节外生枝的问题，还望您或其他人能确认一下。您第一次的回复里提到“一般rootvg要做镜像的，hd6必须镜像，但dump设备没必要……”，我在想hd6肯定必须镜像，那对于非hd6的其它paging space是否也需要镜像呢？我自己认为从节省空间和提高性能两方面来考虑，这些paging space都是不镜像为好。不知道对不对？

作者: beginner-bj 发布时间: 2005-12-20

原帖由 workaholic 于 2005-12-20 12:49 发表
beginner-bj技术其实很厉害的。

搬个板凳学习

谢谢，谢谢！

我发现很多自己以前自以为理解的东西，都经不住推敲。越细想，越是糊涂。

总之，水平的确有限，还望以后各位老大多多指点。

作者: beginner-bj 发布时间: 2005-12-20

对于非hd6的其它paging space也需要镜像，除非是swapoff的——否则，一旦其中一个硬盘坏掉，这部分paging space里的内容没了，必然宕机。

作者: 老农发布时间: 2005-12-20

原帖由 beginner-bj 于 2005-12-20 10:32 发表
这里可以看到在不压缩的情况下Estimated dump size in bytes: 1186988032 （1187M），即不是7808 MB，也不是7808 MB+512MB或7808 MB+512MB*5%

在压缩的情况下Estimated dump size in bytes: 237397606 （237M），这个比hd6还小，显然如果这台实际的机器用hd6来做dump device，可以删掉lg_dumplv，节省了1024 MB的空间。

这个问题我也想过，说说小弟的愚见。我认为，Problem Determination的思想永远不是“copy data”，而是“collect data”，我们需要的是“收集数据”来确定问题，而不是去“复制数据”。因此dumpdev的大小不会也不应该与实际内存相同（如果相同或相近我反而觉得是一种失败）。

至于hd6与hd7为什么要合并的原因，我想任何的计算机系统，无论大到OS，小到一个procedure，都会有一个内聚度与耦合度的概念。合理地增大耦合度可以适当减小管理上的开销，想一想C语言为什么要有union这个数据结构存在。hd6与hd7合并我觉得也是这个原因。但增加系统的耦合度是一个很敏感的问题，当耦合的规模达到某一临界值时，就有可能大大增加管理上的负担，我想这里临界值应该就是4G的内存大小。因此在内存大于4G时候需要对DUMPDEV做额外处理是可以理解的。

不过我想楼主最关心的可能就是那“大大增加的管理负担”具体是怎么一种情况，以至与非得把DUMPDEV独立出来。我也想知道，可是我觉得这不是一个简单的问题，这是另外一门学科，是programmer领域的问题，而我们的工作是Administrator，programmer需要深入细节，而Administrator则首先需要把握思想。也许你会说，一个不具备programmer精神的Administrator可能不是称职的，的确，我也认为是这样，一句话，功到自然成。好多东西，随着学习的深入，慢慢就理解了。加油加油呵呵

作者: qy196 发布时间: 2005-12-21

原帖由 qy196 于 2005-12-21 16:29 发表

这个问题我也想过，说说小弟的愚见。我认为，Problem Determination的思想永远不是“copy data”，而是“collect data”，我们需要的是“收集数据”来确定问题，而不是去“复制数据”。因此dumpdev的大小不会 ...

说得好啊，而且看问题的点也和一般人不一样，有高度。向你学习

作者: beginner-bj 发布时间: 2005-12-21

明白啦。

作者: wcp2004 发布时间: 2005-12-22

以各位前辈为榜样！好好学习！学习学习！

作者: 门对寒流发布时间: 2005-12-22

原帖由 larryh 于 2005-12-20 08:41 发表
■内存小于4GB的时候，paging space的空间划分原则基本上能够保证paging space不小于内存大小，因此当然能够容纳系统DUMP，这样，paging space无需为系统DUMP的考虑而占用更多空间
■当内存大于4GB的时候，pag ...

那如果使用其他dump设备，那镜像是否有必要，下面的帖子中农哥说“
对于非hd6的其它paging space也需要镜像，除非是swapoff的——否则，一旦其中一个硬盘坏掉，这部分paging space里的内容没了，必然宕机。”
larryh大哥能否详细解答一下！！

作者: kingdanis 发布时间: 2006-12-26

dump设备如果镜像就错了。
但paging设备应该镜像，否则没保护

作者: 老农发布时间: 2006-12-26

我对sysdump的概念理解有误
# sysdumpdev -l
primary /dev/hd6
secondary /dev/sysdumpnull
copy directory /var/adm/ras
forced copy flag TRUE
always allow dump FALSE
dump compression ON

请问下这个copy directory /var/adm/ras 指的是什么呢？
每次errpt报sysdump空间不够的时候，我就去清/var，报错信息就不出现了。

作者: alligator 发布时间: 2006-12-26

最近也碰到了一个dump问题，正好拿出来分享一下，大家给点意见!!

LABEL: CORE_DUMP_FAILED

IDENTIFIER:45C7A35B

Date/Time: Fri Dec 22 16:54:38 BEIS

Sequence Number: 7283

Machine Id: 0058523D4C00

Node Id: safe1

Class: S

Type: PERM

Resource Name: SYSPROC

Description

SOFTWARE PROGRAM ABNORMALLY TERMINATED

Probable Causes

INTERNAL SOFTWARE ERROR

SYSTEM RUNNING OUT OF PAGING SPACE

User Causes

USER GENERATED SIGNAL

Failure Causes

CORE DUMP FAILED - SEE A REASON CODE BELOW

Recommended Actions

DEFINE ADDITIONAL PAGING SPACE

RERUN THE APPLICATION PROGRAM

IF PROBLEM PERSISTS THEN DO THE FOLLOWING

CONTACT APPROPRIATE SERVICE REPRESENTATIVE

Detail Data

SIGNAL NUMBER

11

USER'S PROCESS ID:

26912

REASON CODE

13

USER ID

212

PROCESSOR ID

0

CORE FILE NAME

/core

PROGRAM NAME

safeInServer

得到一个说法,在里面说到了这个core_dump，而且具解释它有自己一个path，可以用命令syscorepath来定义，刚才上面所写到的这REASON CODE可以查到是212用户对于这个PATH的PERMISSION有问题,所以导致CORE DUMP FAILED.
另外在系统中有一个fullcore属性:
# lsattr -El sys0 | grep fullcore -> 查看属性
fullcore false Enable full CORE dump True
# chdev -l sys0 -a fullcore=true -> 修改属性变为TRUE
----这个fullcore有点不明白,哪位大哥可以解答一下!!!??

作者: kingdanis 发布时间: 2006-12-26

LS说的是一个程序的dump，不是系统dump。是这个程序的问题。

copy directory /var/adm/ras 是指的系统dump后，启动机器时，在dumpdev上的dump内容要copy到的目录。dumpdev是裸设备，数据不是以文件的形式存在的。

作者: 老农发布时间: 2006-12-26

个人觉得dump不是用来恢复数据的，只能在某个时间点上反映系统的工作状态
前面一位兄弟说的"收集数据"，我觉得很有道理。
另外，大家肯定都认为dump数据是从内存里面来的，我也不否认。
至少我还没有确认是不是一部分adapter的cache也会掺和近来，他们有他们自己的垃圾箱。

那么，就跟内存的使用有关了。
dump肯定要记录目前CPU run queue里面的东西，R/T/S之类的 thread状态肯定要记下来；
小鸡的内存肯定是采用了ECC+ChipKill的，那么校验信息肯定是没啥用了，至少我觉得记下来难道用来恢复之前的错误数据？我觉得没有意义，从内存里面吐到硬盘上，肯定要小一些；
VMM的Page Free List我觉得就没有必要记录了，虽然会反映出系统pi/po/fault之类的信息，但是哪些页是空的，只能给lrud进程选择page对象有用，应该跟当下的系统运行任务和状态关系不大；
shared code segment要被保存，需要知道它被那些process share了；
Translation Lookaside Buffer和Page Frame Table肯定要被保存的；
Persitent Segment要被保存，因为这个直接涉及到哪些excutable program被调入了；
我觉得working segment应该不需要保存，这个东西保存下来好像没啥用；
缺页故障统计信息那个表，我觉得肯定是非常重要的；
其他的就是那些kernal之流的信息肯定会抓下来。

分析dump的工作对于我来说还很遥远，希望有过分析经验的高手们出来指点一下吧。
larryh、农哥，各路大侠，快来呀！

作者: crazyshow 发布时间: 2006-12-26

不了解内核的分析它也没什么用。
AIX的内核不公开，所以分析比较困难。

利用dump，可以窃取一些信息，呵呵。

作者: 老农发布时间: 2006-12-26

曾经遇到一个号称可以看懂的人，剧NB，仰望...

作者: crazyshow 发布时间: 2006-12-27

号称和实际也许有很大的差距。
sinister是自己猜测反编译呢，呵呵。

作者: 老农发布时间: 2006-12-27

受教了关于sysdumpdev这个命令请问加上-K参数该如何解析 man看了下，说什么密钥方式开关。。。。不太明白，求解析！

作者: sendmail 发布时间: 2011-05-27