Chinaunix首页 | 论坛 | 博客
  • 博客访问: 667335
  • 博文数量: 128
  • 博客积分: 265
  • 博客等级: 二等列兵
  • 技术积分: 1464
  • 用 户 组: 普通用户
  • 注册时间: 2011-09-27 20:44
个人简介

just do it

文章分类

全部博文(128)

文章存档

2023年(1)

2020年(1)

2019年(1)

2018年(3)

2017年(6)

2016年(17)

2015年(16)

2014年(39)

2013年(34)

2012年(10)

分类:

2014-04-09 10:50:59

原文地址:Solaris系统资源管理(4) 作者:js_jammy

Part 4 系统信息的管理

了解系统的运行状况的首要前提是收集系统信息。Solaris系统具有自己的信息管理系统。本章重要讲述的就是系统信息的管理。
1 信息管理概述
Solaris系统信息共有三个类型:日志信息、Core信息和Crash信息。显示系统信息的地方通常是控制台和日志文件。当然,Solaris系统也提供控制台信息转储的方法。
对于显示在系统控制台中的,系统信息的内容一般如此:
[ID msgid facility.priority]
举例说明:
[ID 672855 kern.notice] syncing file systems...
如果信息来自于内核,内核的名字会显示出来,比如:
Oct 1 14:07:24 mars ufs: [ID 845546 kern.notice] alloc: /: file system full
当系统崩溃时,可能在控制台显示的信息是这样:
panic: error message
在不经常的情况下,下面的信息可能会替代panic信息:
Watchdog reset !
在日志中,记录日志程序syslogd可以自动记录各种系统的警告和错误信息。在默认情况下,很多系统信息显示在系统控制台并存储在/var/adm目录中。当系统发生问题,比如有些设备发生了故障时这些信息能给出警告。
/etc/adm目录包含着几个信息文件。最新的信息是存储在/var/adm/messages文件中。经过一段时间之后(通常是每10天),新的消息文件就会被创建,这时messages.0文件就改名为messages.1,messages.1该为messages.2,messages.2改为messages.3等。而原来的messages.3文件将被删除。
因为/var/adm目录存有大容量的信息文件、crash文件和其他数据文件,所以这个目录需要大的磁盘空间。你应该删除在这个目录中的一些不需要的文件。
要想查看当前系统内核崩溃信息或重新启动信息,请使用dmesg命令。当然也可以直接到/var/adm/messages文件中去查看。
dmesg命令输入如下所示:
$ dmesg
Jan 3 08:44:41 starbug genunix: [ID 540533 kern.notice] SunOS Release 5.10 ...
Jan 3 08:44:41 starbug genunix: [ID 913631 kern.notice] Copyright 1983-2003 ...
Jan 3 08:44:41 starbug genunix: [ID 678236 kern.info] Ethernet address ...
Jan 3 08:44:41 starbug unix: [ID 389951 kern.info] mem = 131072K (0x8000000)
Jan 3 08:44:41 starbug unix: [ID 930857 kern.info] avail mem = 121888768
Jan 3 08:44:41 starbug rootnex: [ID 466748 kern.info] root nexus = Sun Ultra 5/
10 UPA/PCI (UltraSPARC-IIi 333MHz)
Jan 3 08:44:41 starbug rootnex: [ID 349649 kern.info] pcipsy0 at root: UPA 0x1f0x0
Jan 3 08:44:41 starbug genunix: [ID 936769 kern.info] pcipsy0 is [url=]/pci@1f,0[/url]
Jan 3 08:44:41 starbug pcipsy: [ID 370704 kern.info] PCI-device: [email=pci@1,1]pci@1,1[/email], simba0
Jan 3 08:44:41 starbug genunix: [ID 936769 kern.info] simba0 is [url=]/pci@1f,0/pci@1,1[/url]
Jan 3 08:44:41 starbug pcipsy: [ID 370704 kern.info] PCI-device: [email=pci@1]pci@1[/email], simba1
Jan 3 08:44:41 starbug genunix: [ID 936769 kern.info] simba1 is [url=]/pci@1f,0/pci@1[/url]
Jan 3 08:44:57 starbug simba: [ID 370704 kern.info] PCI-device: [email=ide@3]ide@3[/email], uata0
Jan 3 08:44:57 starbug genunix: [ID 936769 kern.info] uata0 is [url=]/pci@1f,0/pci@1[/url],
[email=1/ide@3]1/ide@3[/email]
Jan 3 08:44:57 starbug uata: [ID 114370 kern.info] dad0 at pci1095,6460

2 系统日志信息管理

日志(log)是最常见的日志形式。本节主要介绍日志的利用和管理。
系统日志循环利用
系统日志文件是通过在/etc/crontab文件中设定,定时启动logadm命令来完成循环利用的。创建新的日志记录的脚本程序/usr/lib/newsyslog并不经常起用。
系统日志循环是定义在/etc/logadm.conf文件中的,这个文件包含着日志进程的循环条目。比如,其中一个条目就是关于/var/log/syslog文件每周循环的,最新的syslog文件成为syslog.0文件,而syslog.0成为syslog.1文件等。一共保存8个以前的日志文件。
在/etc/logadm.conf中,你可以定制系统日志或增加系统日志的记录。
比如,循环增加apache的访问和错误日志,就用下列命令:
# logadm -w /var/apache/logs/access_log -s 100m
# logadm -w /var/apache/logs/error_log -s 10m
在这个例子中,apache的access_log文件当达到100MB时是循环使用的,使用的文件后缀是0,1,2等,一共保存10个access_log文件的拷贝。error_log也是循环的,当它达到10MB的时候停止保存。
定制系统日志信息
定制系统日志信息输出的文件是/etc/syslog.conf文件。在/etc/syslog.conf文件中,默认设置下,很多系统进程信息被保存到/var/adm/messages 文件。crash和启动信息也可以这里设置。
下面就是/etc/syslog.conf文件的内容:
user.err /dev/sysmsg
user.err /var/adm/messages
user.alert ‘root, operator’
user.emerg *
这意味着下列信息可以自动记录:
 用户的错误打印在控制台上并且记录在/etc/adm/messages文件中
 要有一个动作(alert)来响应信息,这个动作给root或操作的用户发送警告。
 用户的紧急情况信息要发送给每个人。
在syslog.conf文件中的资源工具:
资 源--描 述
kern--内核
auth--权限
daemon--所有后台程序
mail--邮件系统
lp--打印系统
user--用户进程

在syslog.conf文件中的优先级列表:
优 先 级--描 述
emerg--系统突发紧急事件
alert--错误要求马上修正
crit--危急的错误
err--其他错误
info--情报信息
debug--输出用户调试信息
none--设定不进行日志输出

下面举例说明如何定制日志信息:
 例17-1 定制日志信息。
(1)成为超级用户或等同角色用户。
(2)编辑/etc/syslog.conf文件,增加下面的内容,将用户的突发事件信息发送给超级用户和每个用户。
user.emerg ‘root, *’
(3)退出保存。





jnet
(2009-7-11 10:22:57)
3 系统core文件的管理

core文件是系统软件出现问题后产生的信息记录。它对软件开发者和系统管理者的工作有很大的帮助作用。本节主要对Core文件产生和管理做一些初步介绍。
管理core文件概述
core文件在进程或者应用程序异常终止时产生。我们可以使用coreadm命令来管理core文件。比如,你可以使用coreadm命令来设定所有的core文件都放在一个目录中。这样,就会很容易通过测试找到问题的痕迹。
有两种类型的core文件:
 单个进程的core文件,在默认情况下是启动的。当进程异常终止时,单个进程的core文件就在异常终止进程的目录中产生。产生后,单个进程的core文件的拥有者就是进程的拥有者。只有拥有者才能查看这个文件。
 全局core文件,它默认的情况下是不开启的。如果启动了全局core文件,它产生在引起全局core文件产生的目录。全局core文件的拥有者就是超级用户。非特权用户不能查看全局core文件。
当进程异常终止时,默认在当前目录产生core文件。如果这时全局core文件路径也开启着,每个异常终止的进程就会有两个文件产生:一个在当前的工作目录;另一个在全局core文件目录。
默认时,setuid进程既不产生全局core文件也不产生单个core文件。
如果全局core文件是开启的,core文件可以用下表中的变量所描述。
描述Core文件的变量:
变 量 名--变量描述
%d--执行的文件目录名
%f--执行的文件名
%g--组的ID
%m--机器名称
%n--系统节点点
%p--进程ID
%t--十进制的时间
%u--有效的用户ID
%z--进程运行的分区(xone)名
%%--百分比

举例说明,全局core文件路径设置为:
/var/core/core.%f.%p
这时,如果sendmail的PID为12345的进程发生异常终止,将产生下列core文件:
/var/core/core.sendmail.12345
我们可以使用coreadm命令设定进程产生的core文件的目录和名称。这将取代原来的默认设置。
# coreadm -i /var/core/core.%f.%p
全局core的属性值存储在/etc/coreadm.conf文件中。
管理core文件的实例
1.显示当前core文件的设置

 例17-2 使用不带任何参数的coreadm命令显示当前core的设置情况。
$ coreadm
global core file pattern:
global core file content: default
nit core file pattern: core
init core file content: default
global core dumps: disabled
per-process core dumps: enabled
global setid core dumps: disabled
per-process setid core dumps: disabled
global core dump logging: disabled
2.设置core文件名的样式

将当前Shell运行的所有进程所产生的core文件命名:
$ coreadm -p $HOME/corefiles/%f.%p $$
对全局文件设置core文件命名需要超级用户权限:
# coreadm -g /var/corefiles/%f.%p
3.启用单个进程core文件的路径

# coreadm -e process
$ coreadm $$
1180: /home/kryten/corefiles/%f.%p
4.启用全局core文件的路径

# coreadm -e global -g /var/core/core.%f.%p
查询core文件信息
一些proc工具可以像检测活动的进程一样检测core文件。比如,/usr/proc/bin/pstack、pmap、pldd、pflags和pcred工具能管理core文件。更详细的信息请查看porc(1)的帮助。
 例17-3 使用proc工具检查core文件。
$ ./a.out
Segmentation Fault(coredump)
$ /usr/proc/bin/pstack ./core
core ’./core’ of 19305: ./a.out
000108c4 main (1, ffbef5cc, ffbef5d4, 20800, 0, 0) + 1c
00010880 _start (0, 0, 0, 0, 0, 0) + b8

4 系统crash信息的管理

crash主要反馈主机能否正常运行等比较严重的问题。系统管理员需要特别关注crash信息。
系统崩溃概述
系统崩溃(crash)发生在硬件故障、I/O问题或软件错误的情况下。如果系统崩溃发生了,它将在控制台上显示错误信息,并将物理内存的拷贝写入转储设备。这时,系统将自动重新启动。当系统重启后,savecore 命令运行将数据从转储设备中找回,并存储到savecore目录。这些数据为系统诊断提供了依据。
系统崩溃转储文件

当savecore命令自动运行将崩溃信息从转储设备中找回,并写成两个文件:unix.X和vmcore.X。其中X为转储的次序号码。这些文件一起用于表现系统的崩溃转储信息。
崩溃转储文件存储在预先设定好的目录中,默认情况下是/var/crash/hostname。在以前的Solaris版本中,崩溃转储文件将在系统重新启动的时候不写在特定的目录,除非你手动启动,将内存的映像存储到崩溃转储文件中。不过现在就自动存储崩溃转储文件了。
dumpadm命令

我们可以用dumpadm命令来在Solaris系统中管理系统崩溃转储信息。
 dumpadm命令能使你在操作系统上设置崩溃转储。这个命令的设置参数包括转储的内容、转储的设备和崩溃转储信息的存储路径。
 转储数据是以压缩的形式被存在转储设备中的。内核的崩溃转储映像可能达到4GB,压缩数据就意味着更快的转储速度和更小的转储设备磁盘空间。
 保存崩溃转储文件是在后台运行的崩溃转储文件的任务。系统启动的时候不需要等待savecore命令完成就可以进行下一步。当然,大的内存数量是有利于savecore完成任务的。
 系统崩溃转储文件是由savecore命令产生的,保存一般也是按默认路径进行的。
 savecore –L命令是新的属性,它使你能在系统运行的时候崩溃转储。当系统内存存储有问题的时候,这个命令试图在系统运行的时候调试内存的快照。如果系统是启动的,并且有些命令还能执行,你可以运行cavecore –L命令来存储系统转储设备的快照到崩溃转储目录。
通过dumpadm命令,转储设置参数存储在/etc/dumpadm.conf文件中。注意不要手动编辑这个文件,这样做可能会带来不一致的转储设置。
dumpadm命令如何工作

当系统启动的时候,dumpadm命令调用svc:/system/dumpadm:default服务来设置基于/etc/dumpadm.conf文件的的崩溃转储参数。
dumpadm命令通过/dev/dump接口来初始化转储设备和转储内容。
管理系统崩溃转储信息
在管理系统崩溃信息中,你必须要记住以下几点:
 你必须是超级用户或具有管理系统崩溃功能的用户。
 不要关闭保存崩溃转储信息的属性。系统崩溃转储文件提供了导致系统崩溃的很珍贵的信息。
 不要轻易删除系统崩溃信息。
1.如何显示当前的崩溃转储设置

# dumpadm
Dump content: kernel pages
Dump device: /dev/dsk/c0t3d0s1 (swap)
Savecore directory: /var/crash/venus
Savecore enabled: yes
上面输出的意义如下:
 转储内容是内核内存的换页。
 内核内存将转储到swap设备中,就是/dev/dsk/c0t3d0s1。
 系统崩溃转储文件存在/var/crash/venus目录。
 系统的崩溃转储功能是启动着的。
2.如何修改当前的崩溃转储设置

命令介绍
# dumpadm -c content -d dump-device -m nnnk | nnnm | nnn% -n -s savecore-dir
dumpadm命令的各个参数具体意义列在下表中。
dumpadm命令的参数列表:
转储参数--描 述
-c content--转储的数据类型。默认的转储内容是内核的内存。使用all关键字是指所有内存
-d dump-device--系统崩溃时,临时存储的专门设备
-m nnnk | nnnm | nnn%--在savecore目录中为了存储崩溃转储文件所留的专门空间。这个参数有可能是kb(nnnk),也有可能mb(nnnm),也有可能是百分比(nnn%)

 例17-4 转储内容改为所有内存,转储目录改为/dev/dsk/c0t1d0s1,转储空间最大为这个文件系统的10%。
先查看原来的转储设置:
# dumpadm
Dump content: kernel pages
Dump device: /dev/dsk/c0t3d0s1 (swap)
Savecore directory: /var/crash/pluto
Savecore enabled: yes
更改转储设置:
# dumpadm -c all -d /dev/dsk/c0t1d0s1 -m 10%
Dump content: all pages
Dump device: /dev/dsk/c0t1d0s1 (dedicated)
Savecore directory: /var/crash/pluto (minfree = 77071KB)
Savecore enabled: yes
3.如何检查崩溃转储文件内容

 例17-5 使用mdb工具输出崩溃转储文件内容,其中包括系统信息和在/etc/system文件中可调用的一些参数。
# /usr/bin/mdb -k unix.0
Loading modules: [ unix krtld genunix ip nfs ipc ptm ]
> ::status
debugging crash dump /dev/mem (64-bit) from ozlo
operating system: 5.10 Generic (sun4u)
> ::system
set ufs_ninode=0x9c40 [0t40000]
set ncsize=0x4e20 [0t20000]
set pt_cnt=0x400 [0t1024]

-n 或-y--是否自动进行崩溃转储,y为是,n为否
-s savecore-dir--用来改变崩溃转储文件的路径。默认路径是/var/crash/hostname
阅读(1254) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~