happyman

[mysql]在用limit查询的同时取得总的记录数

1.什么是NFS(Network FileSystem)
 NFS 就是 Network FileSystem 的缩写，最早之前是由 Sun 所发展出来的。他最大的功能就是可以透过网络，让不同的机器、不同的操作系统、可以彼此分享个别的档案 ( share file )，所以，也可以简单的将他看做是一个 file server 呢！这个 NFS Server 可以让你的 PC 来将网络远程的 NFS 主机分享的目录，挂载到本地端的机器当中，所以，在本地端的机器看起来，那个远程主机的目录就好象是自己的 partition 一般！
 虽然 NFS 有属于自己的协议与使用的 port number ，但是在资料传送或者其它相关讯息传递的时候， NFS 使用的则是一个称为远程过程调用( Remote Procedure Call, RPC )的协议来协助 NFS 本身的运作！

2.RPC
 当我们在使用某些服务来进行远程联机的时候，有些信息，例如主机的IP、服务的 port number、与对应到的服务之 PID 等等，都需要管理与对应！这些管理 port 的对应与服务相关性的工作，就是这个 Remote Procedure Call, RPC 的任务了
 NFS 本身的服务并没有提供资料传递的协议，但是 NFS 却能让我们进行档案的分享，这其中的原因，就是 NFS 使用到一些其它相关的传输协议！而这些传输的协议，就是使用到这个所谓的 RPC 的功能啰！这也就是说， NFS 本身就是使用 RPC 的一个 program 就是了！说的更白话一点， NFS 也可以视作是一个 RPC server 啦！同时要注意到的是，在某些状况中，不但跑 NFS 的 Server 需要激活 RPC 的服务，连带的，要挂载 NFS partition 的 Client 机器，也需要同步激活 RPC 才行！这样 Server 端与 Client 端才能藉由 RPC 的协议来进行 program port 的对应喔！NFS 主要在管理分享出来的目录，而至于资料的传递，就直接将他丢给 RPC 的协议来运作就是了！

3.NFS 激活的 RPC daemons
 o rpc.nfsd：这个 daemon 主要的功能就是在管理 Client 是否能够登入主机的权限啦，其中还包含这个登入者的 ID 的判别
 o rpc.mountd：这个 daemon 主要的功能，则是在管理 NFS 的档案系统！当 Client 端顺利的通过 rpc.nfsd 而登入主机之后，在他可以使用 NFS server 提供的档案之前，还会经过档案使用权限 ( 就是那个 -rwxrwxrwx 与 owner, group 那几个权限啦 ) 的认证程序！他会去读 NFS 的设定档 /etc/exports 来比对 Client 的权限，当通过这一关之后， Client 就可以取得使用 NFS 档案的权限啦！(注：这个也是我们用来管理 NFS 分享之目录的使用权限与安全设定的地方哩)

4.NFS需要有两个套件才行，分别是:
 nfs-utils
 就是提供 rpc.nfsd 及 rpc.mountd 这两个 NFS daemons 与其它相关 documents 与说明文件、执行档等的套件！这个就是 NFS 的主要套件
 portmap
 就如同刚刚提的到，我们的 NFS 其实可以被视为一个 RPC server program，而要激活任何一个 RPC server program 之前，我们都需要做好 port 的对应 ( mapping ) 的工作才行，这个工作其实就是『 portmap 』这个服务所负责的！也就是说，在激活任何一个 RPC server 之前，我们都需要激活 portmap 才行呢！那么这个 portmap 到底在干嘛呢？就如同这个服务的名称，哈哈！就是作 port 的 mapping 啊！举个例子来说：当 Client 端尝试来使用 RPC server 所提供的服务时，由于 Client 需要取得一个可以连接的 port 才能够使用 RPC server 所提供的服务，因此， Client 首先就会去跟 portmap 讲『喂！可不可以通知一下，给我个 port number ，好让我可以跟 RPC 联络吧！』这个时候 portmap 就自动的将自己管理的 port mapping 告知 Client ，好让他可以连接上来 server 呢！所以啰：『激活 NFS 之前，请先激活 portmap ！』

5.NFS server端的设定:
 a)./etc/exports
 分享的目录 主机名称1或IP1(参数1，参数2) 主机名称2或IP2(参数3，参数4)
 b).参数
 rw: 可擦写的权限
 ro: 只读的权限
 no_root_squash: 登入 NFS 主机使用分享目录的使用者，如果是 root 的话，那么对于这个分享的目录来说，他就具有 root 的权限！这个项目『极不安全』，不建议使用！
 root_squash: 在登入 NFS 主机使用分享之目录的使用者如果是 root 时，那么这个使用者的权限将被压缩成为匿名使用者，通常他的 UID 与 GID 都会变成 nobody 那个身份；
 all_squash: 不论登入 NFS 的使用者身份为何，他的身份都会被压缩成为匿名使用者，通常也就是 nobody 啦！
 anonuid: 前面关于 *_squash 提到的匿名使用者的 UID 设定值，通常为 nobody，但是你可以自行设定这个 UID 的值！当然，这个 UID 必需要存在于你的 /etc/passwd 当中！
 anongid: 同 anonuid ，但是变成 group ID 就是了
 sync: 资料同步写入到内存与硬盘当中
 async: 资料会先暂存于内存当中，而非直接写入硬盘

6.设置的实例:
 a). /tmp *(rw,no_root_squash)  //*号表示所有的IP都可以访问
 b). /tmp *(rw)
  /home/public 192.168.0.*(rw) *(ro)  //下面两行作用一样
  /home/public 192.168.0.0/24(rw) *(ro)
 c). /home/test 192.168.0.100(rw) //只对某部机器设置权限
 d). /home/linux *.linux.org(rw,all_squash,anonuid=40,anongid=40) //当*.linux.org登陆此NFS主机，并且在/home/linux下面写入档案时，该档案的所有人与所有组，就会变成/etc/passwd里面对应的UID为40的那个身份的使用者了.
 
7.权限问题
假设/etc/exports里面的内容为
 #vi /etc/exports
 /tmp *(rw,no_root_squash)
 /home/public 192.168.0.*(rw) *(ro)
 /home/test 192.168.0.100(rw)
 /home/linux *.linux.org(rw,all_squash,anonuid=40,anongid=40)
 假设我们在192.168.0.100这个client端登陆此NFS主机(192.168.0.2),那么
 情况一:在192.168.0.100的帐号为test这个身份，同时，NFS主机上也有test这个帐号
  a).由于NFS主机的/tmp权限为-rwxrwxrwt，所以我(test在192.168.0.100上)在/tmp下面具有存取的权限，并且写入档案的所有人为test.
  b).在/home/public中，由于我有读写的权限，如果NFS主机在/home/public这个目录的权限对于test开放写入的话，那么就可以读写，并且写入档案的所有人是test。如果NFS主机的/home/public对于test这个使用者并没有开放写入权限时，那就无法写入，虽然/etc/exports里面是rw，也不起作用.
  c).在/home/test中，权限与/home/public有相同的状态，需要NFS主机的/home/test对于test有开放的权限.
  d).在/home/linux当中，不论是何种的user,身份都会被变成UID=40的这个帐号
 情况二:如果我们在192.168.0.100的身份为test2,但是NFS主机却没有test2这个帐号时
  a).在/tmp下还是可以写入，但是写入的档案所有人变成nobody.
  b).在/home/public与/home/test里面是否可以写入，还需要看/home/public的权限而定，不过身份就被变成nobody了
  c)/home/linux下的身份还是变成UID=40的帐号.
 情况三:在192.168.0.100的身份为root
  a).在/tmp里面可以写入，但是由于no_root_squash的参数，改变了预设的root_squash的设定值，所以在/tmp写入档案的所有人为root了.
  b).在/home/public底下的身份被压缩成了nobody,因为预设的属性都具有root_squash，所以档案所有人就变成了nobody.
  c)./home/test情况与/home/public相同.
  d)./home/linux中，root的身份也被压缩成UID=40的那个使用者了.

8.启动服务portmap,nfs
 #/etc/rc.d/init.d/portmap start  (or:#service portmap start)
 #/etc/rc.d/init.d/nfs start   (or:#service nfs start)
 可以到/var/log/messages里面查看是否正确激活
9.exportfs的用法
 如果我们修改了/etc/exports后，并不需要重启nfs服务，只要用exportfs重新扫描一次/etc/exports，并且重新加载即可
 语法: exportfs [-aruv]
 -a: 全部挂载(或卸载) /etc/exports档案内的设定
 -r: 重新挂载/etc/exports里面的设定，也同步的更新/etc/exports和/var/lib/nfs/xtab里面的内容
 -u:卸载某一目录
 -v:在export的时候，将分享的目录显示到荧屏上.
 例子
 #exportfs -rv //重新export一次
 #exportfs -au //全部卸载

10./var/lib/nfs/xtab里面可以查看每个目录的分享权限(但是我怎么也没有找到，靠,找到了，原来要有人mount上nfs后才会出现内容)，如:
/tmp    node3(ro,sync,wdelay,hide,secure,root_squash,no_all_squash,subtree_check,secure_locks,mapping=identity,anonuid=-2,anongid=-2)
 为什么anonuid=-2呢？呵呵！其实它说的是将 65536 - 2 的值，也就是 65534 的那个 UID 啦！对照一下 /etc/passwd ，你就会发现，哇！原来那就是 nobody 的啦

11.showmount命令
 语法: showmount [-ae] hostname
 -a: 显示目前主机与client所连上来的使用目录的状态
 -e: 显示hostname的/etc/exports里面共享的目录

12.查看激活的portnumber
 #netstat -utln
 nfs 自己所开启的 port ，就是那个 2049 的 port 啦！就是 NFS 主要产生的 port NFS server 在前面我们就提过了，他是 RPC server 的一种，而 NFS 由于提供了多个 program ( 例如 rpc.mountd, rpc.rquotad, rpc.nfsd... ) ，因此就需要激活多个 port 了！而且这些 port 是『随机产生的』，也就是那个 port number 不会是固定的啦！每次 restart nfs 都会得到不一样的 port number 呢！那么 Client 端怎么知道要连接上那个 port 来呼叫需要的 program 呢？呵呵！那就是 sunrpc ( port 111 ) 那个 portmap 服务所产生的 port number 的功用啦！Client 会先连接到 sunrpc 那个 port 去知道应该到那个 port 去呼叫所需要的程序！所以啰， rpc.xxxx 等之类的 daemon 自然就不需要有固定的 port number 啰！

***********************************************
NFS客户端的设定
 #mount -t nfs hostname(orIP):/directory /mountpoint   搞定，就这么简单
 为了担心会不小心将 NFS 端挂进来的具有 SUID 权限档案的程序执行，root可以将NFS 所分享的目录以较为安全的情况挂载进来，可以
 #mount -t nfs -o nosuid,ro hostname:/directory /mountponit

可能出问题的地方:
1.权限的设定不符合
2.忘记了激活portmap,此时会报错:
 mount: RPC: Port mapper failure - RPC: Unable to receive 或者
 mount: RPC: Program not registered
 那么，启动portmap，并且重新启动nfs
 #service portmap start
 #service nfs restart
3.被防火墙搞掉
 重新设置防火墙,包括iptables与TCP_Wrappers,因为激活了portmap，所以port 111必须提供出去.因此在iptables rules中，要增加:
 iptables -A INPUT -p TCP --dport 111 -j ACCEPT
 iptables -A INPUT -p UDP --dport 111 -j ACCEPT
 如果还不行，那就是TCP_Wrappers的问题，检查/etc/hosts.deny，如果有一行是:
  ALL: ALL: deny
 那就必须在/etc/hosts.allow中增加:
  portmap: ALL: allow
 如果我们的NFS针对内部网络开发，对于外部网络只对学术网络开发(140.0.0.0/8)，可以:
  iptables -A INPUT -i eth0 -p TCP -s 192.168.0.0/24 --dport 111 -j ACCEPT
  iptables -A INPUT -i eth0 -p UDP -s 192.168.0.0/24 --dport 111 -j ACCEPT
  iptables -A INPUT -i eth0 -p TCP -s 140.0.0.0/8 --dport 111 -j ACCEPT
  iptables -A INPUT -i eth0 -p UDP -s 140.0.0.0/8 --dport 111 -j ACCEPT
 还可以使用TCP_Wrappers，在/etc/hosts.allow里面规定连上 NFS 主机的主机 IP 与名称，例如
 #vi /.etc/hosts.allow
 portmap: 192.168.0.0/255.255.255.0 :allow
 portmap: 140.113.23.23    :allow
 portmap: .sdu.edu.cn    :allow
 
RPC Server的相关命令
 rpcinfo
 #rpcinfo -p hostname(orIP)
 
要注意的问题:
 需要注意的是，由于 NFS 使用的这个 RPC 在 client 端连上主机时，那么你的主机想要关机，那可就会成为『不可能的任务』！我还不知道正确的原因是什么，但是，如果你的 Server 上面还有 Client 在联机，那么你要关机，可能得要等到数个钟头才能够正常的关机成功！嗄！真的假的！不相信吗？不然您自个儿试试看！ ^_^！所以啰，建议您的 NFS Server 想要关机之前，能更先『关掉 portmap 与 nfs 』这两个东西！如果无法正确的将这两个 daemons 关掉，那么先以 netstat -utlp 找出 PID ，然后以 kill 将他关掉先！这样才有办法正常的关机成功喔！这个请特别特别的注意呢！
 
 在TurboLinux8.0 for AMD64 (kernel 2.4.21-4smp),mount NFS时候报错为:
  portmap: server localhost not responding, timed out
 解决办法:
  mount -t nfs -o nolock node1:/public /public
 即增加-o nolock参数,原因:
 Unfsd doesn't support NLM locking, and it's causing the lockd daemon to be started (which again requires the portmapper to be installed etc.)
 
 

1.设置块大小
mount命令的risize和wsize指定了server端和client端的传输的块大小。如果没有指定，那么，系统根据nfs的版本来设置缺省的risize和wsize大小。大多数情况是4K（4096bytes），对于nfs v2，最大是8K，对于v3，在server端设置risize和wsize的限制，最大块大小在kernel的常量NFSSVC_MAXBLKSIZE,该常量在usr/src/linux2.4/include/linux/nfsd/const.h.所有的2.4的的client都支持最大32K的传输块。系统缺省的块可能会太大或者太小，这主要取决于你的kernel和你的网卡，太大或者太小都有可能导致nfs速度很慢。具体的可以使用Bonnie，Bonnie++，iozone等benchmark来测试不同risize和wsize下nfs的速度。当然，也可以使用dd来测试。
 ＃time dd if=/dev/zero of=/testfs/testfile bs=8k count=1024这是来测试nfs写
 ＃time dd if=/testfs/testfile of=/dev/null bs=8k 这是测试nfs读
测试时文件的大小至少时系统RAM的两倍，每次测试都使用umount 和mount对/testfs进行挂载，通过比较不同的块大小，得到优化的块大小。
2.网络传输包的大小
网络在包传输过程，对包要进行分组，过大或者过小都不能很好的利用网络的带宽，所以对网络要进行测试和调优。可以使用ping -s 2048 -f hostname进行 ping，尝试不同的package size，这样可以看到包的丢失情况。同时，可以使用nfsstat －o net 测试nfs使用udp传输时丢包的多少。
因为统计不能清零，所以要先运行此命令记住该值，然后可以再次运行统计。如果，经过上面的统计丢包很多。那么可以看看网络传输包的大小。使用下面的命令：
#tracepath node1/端口号
#ifconfig eth0
比较网卡的mtu和刚刚的pmtu，使用#ifconfig eth0 mtu 16436设置网卡的mtu和测试的一致。

当然如果risize和wsize比mtu的值大，那么的话，server端的包传到client端就要进行重组，这是要消耗client端的cpu资源。此外，包重组可能导致网络的不可信和丢包，任何的丢包都会是的rpc请求重新传输，rpc请求的重传有会导致超时，严重降低nfs的性能。可以通过查看/proc/sys/net/ipv4/ipfrag_high_thresh和/proc/sys/net/ipv4/ipfrag_low_thresh了解系统可以处理的包的数目，如果网络包到达了ipfrag_high_thresh，那么系统就会开始丢包，直到包的数目到达ipfrag_low_thresh。
3.nfs挂载的优化
 
timeo:如果超时，客户端等待的时间，以十分之一秒计算。
retrans：超时尝试的次数。
bg：后台挂载，很有用
hard：如果server端没有响应，那么客户端一直尝试挂载。
wsize：写块大小
rsize：读块大小
intr：可以中断不成功的挂载
noatime：不更新文件的inode访问时间，可以提高速度。
async：异步读写。
4.nfsd的个数
缺省的系统在启动时，有8个nfsd进程。
#ps -efl|grep nfsd
通过查看/proc/net/rpc/nfsd文件的th行，第一个是nfsd的个数，后十个是线程是用的时间数，第二个到第四个值如果很大，那么就需要增加nfsd的个数。
具体如下：
#vi /etc/init.d/nfs
找到RPCNFSDCOUNT,修改该值，一般和client端数目一致。
然后，重启服务。
#service nfs restart
#mount -a
5.nfsd的队列长度
对于8个nfsd进程，系统的nfsd队列长度是64k大小，如果是多于8个，就要相应的增加相应的队列大小，具体的在/proc/sys/net/core/【rw】mem_default和/proc/sys/net/core/【rw】mem_max。队列的长度最好是每一个nfsd有8k的大小。这样，server端就可以对client的请求作排队处理。如果要永久更改此值
#vi /etc/sysctl.conf
加入
net.core.【rw】mem_max=数目
net.core.【rw】mem_default=数目
#service nfs restart

1、让tail不停地读地最新的内容

了解如何将用户抱怨与系统活动报告程序 (SAR) 关联，并使用 SAR 日志针对趋势建立性能基准。SAR 是系统管理员的理想工具。它以周期性的间隔捕获系统性能度量。

用户总是在出现性能问题之后才想到它们。“为什么有些问题以前并不重要，而现在却变得重要了呢？”，如果忽略这样的问题，那么问题就变成了“系统在出现所谓的问题时状态如何呢？”。通过周期性地获取性能快照和查看数据，您就离确定问题的原因并创建相应的解决方案更近了一步。

收集数据

您的系统捆绑了 SAR 实用程序套件（事实上，大多数版本的 UNIX® 都安装了 SAR），但可能还没有启用。要启用 SAR，必须通过 cron 工具以周期性的间隔运行某些实用程序。在以 root 用户身份运行时，使用 crontab -e 命令，然后提供如清单 1 所示的配置。

# Collect measurements at 10-minute intervals
0,10,20,30,40,50   * * * *   /usr/lib/sa/sa1
# Create daily reports and purge old files
0                  0 * * *   /usr/lib/sa/sa2 -A

第一个命令 sa1，是调用 sadc 以将性能数据收集到二进制日志文件中的一个 Shell 脚本。sa1 命令还确保了每天都使用不同的文件，我将在时间是最重要的部分中对这一点进行解释。每隔十分钟运行一次该命令，这是粒度和系统性能影响之间的折衷办法。

第二个命令 sa2，是将当日二进制日志文件中所有的数据转储到文本文件的另一个 Shell 脚本，然后它将清除七天之前的所有日志文件。参数 -A 指定了从二进制文件中提取哪些数据转储到文本文件中。尽管可以阅读文本文件以查看系统该日的状态，但我将介绍如何更精确地查询二进制日志文件。

回页首

提取有用的信息

已经收集到了相应的数据，但是必须通过查询才能使其更有价值。不带选项运行 sar 命令，这将生成关于当日 CPU 使用情况的基本统计信息。清单 2 显示了不带任何选项的 sar 命令的输出结果。（在不同的平台中，可能会看到不同的列名。在一些 UNIX 版本中，sadc 命令将根据可用的信息来收集不同的数据。）这里的示例来自于 Sun Solaris 10，无论使用什么平台都是类似的，但列名可能会稍有不同。

-bash-3.00$ sar

SunOS unknown 5.10 Generic_118822-23 sun4u    01/20/2006

00:00:01    %usr    %sys    %wio   %idle
00:10:00       0       0       0     100
. cut ...
09:30:00       4      47       0      49

Average        0       1       0      98

sar 命令输出中的每一行都是一项单独的度量，并且在最左边的列中显示了时间戳。其他列中则存放了相应的数据。（根据命令行所使用参数的不同，这些列也会有所不同。）在清单 2 中，CPU 使用情况被分解为四种类别：

• %usr： CPU 花费在用户进程（如应用程序、Shell 脚本或与该用户进行的交互）上的时间的百分比。
• %sys： CPU 用来执行核心任务的时间的百分比。在本示例中该数字比较大，这是因为我正从核心随机数生成器获取数据。
• %wio： CPU 等待块设备（如磁盘）输入或输出的时间的百分比。
• %idle： CPU 未进行任何有用操作的时间的百分比。

最后一行是所有数据点的平均值。然而，因为大多数系统都会在忙时间段后经历空闲时间段，所以平均值并不能反映完整的情况。

监视磁盘活动

同时，对磁盘活动也进行了监视。高磁盘使用率意味着，从磁盘请求数据的应用程序更有可能会被阻塞（暂停），直到磁盘为该进程做好准备。通常，解决方案涉及到将文件系统拆分到不同的磁盘或阵列。然而，第一步是要知道出现了问题。

sar -d 的输出显示了一个度量时间段内各种与磁盘相关的统计数据。为了更加简洁，清单 3 仅显示了硬盘驱动器的活动。

$ sar -d

SunOS unknown 5.10 Generic_118822-23 sun4u    01/22/2006

00:00:01   device       %busy   avque   r+w/s  blks/s  avwait  avserv
. cut ...
14:00:02   dad0             31     0.6      78   16102     1.9     5.3
           dad0,c            0     0.0       0       0     0.0     0.0
           dad0,h           31     0.6      78   16102     1.9     5.3
           dad1              0     0.0       0       1     1.6     1.3
           dad1,a            0     0.0       0       1     1.6     1.3
           dad1,b            0     0.0       0       0     0.0     0.0
           dad1,c            0     0.0       0       0     0.0     0.0

和前面的示例一样，最左边的是时间。其他列如下：

• device： 这是指正在进行测量的磁盘或磁盘分区。在 Sun Solaris 中，必须通过查找 /etc/path_to_inst 中所报告的名称将该磁盘转换为物理磁盘，然后将该信息交叉引用到 /dev/dsk 中的项目。在 Linux® 中，使用了磁盘设备的主从设备号。
• %busy： 这是读取或写入设备的时间的百分比。
• avque： 这是用来串行化磁盘活动的队列的平均深度。avque 的值越大，发生的阻塞就越多。
• r+w/s、blks/s：这分别是用每秒的读或写操作和磁盘盘块来表示的磁盘活动。
• avwait：这是磁盘读或写操作等待执行的平均时间（单位为毫秒）。
• avserv：这是磁盘读或写操作所执行的平均时间（单位为毫秒）。

其中的一些数值，如 avwait 和 avserv 值，直接关系到用户体验。磁盘的高等待时间可能表示多个人正在竞争使用该磁盘，这一点可以通过高 avque 数值来证实。高 avserv 值表示磁盘的速度较慢。

其他度量

同时还收集了许多其他的项目，可使用相应的参数来查看它们：

• -b 参数显示了缓冲区信息和使用缓冲区与必须写磁盘的比率。
• -c 参数显示了系统调用分解为一些常用的调用，如 fork()、exec()、read() 和 write()。高进程创建会导致较差的性能，并且这是可能需要将一些应用程序转移到其他计算机的信号。
• -g、-p 和 -w 参数显示了分页（交换）活动。高分页操作是内存缺乏的信号。特别地，-w 选项显示了进程切换的次数：高的数值表示计算机上运行的内容过多，该计算机在切换任务上花费了比实际工作更多的时间。
• -q 参数显示了运行队列的大小，它与当时的平均负载相同。
• -r 参数显示了一段时间的可用内存和交换空间。

每种 UNIX 版本都对 sar 实现了自己的度量集合和命令行参数。我介绍的这些都是比较常见的，并且代表了更加有用的元素。

回页首

时间是最重要的

到此为止，示例显示了当日的数据，它虽然具有相应的作用，但也存在着两个问题：

• 感兴趣的是一个小时内的数据，但获得的是一整天的。
• 需要返回到不同的日期。

正如前面看到的，sa1 将每天的数据保存到不同的文件中。查看 sa1 脚本，会发现所使用的目录，如果是 Sun Solaris 10，该目录为 /var/adm/sa。该目录中有一些文件，它们以“sa”或“sar”开头，后跟一个数字。这个数字表示一个月中的第几天，以“sar”开头的文件是该日数据的文本转储（由夜间运行的 sa2 所创建），而以“sa”开头的文件保存着数据的二进制版本。实际上，包含当前日期的文件是启动 sar 时所读取的文件。

为 sar 命令指定 -f 以选择要读取的文件。如果今天是一个月中的第 23 日，可以使用命令 sar -f /var/adm/sa/sa22 来读取 sa22 以查看昨天的数据。还可以传递介绍过的其他参数以访问不同类型的数据。

可以做的第二件事情是，通过使用 -s 和 -e 参数（即开始 和结束）来指定具体时间以缩小查询的范围。请注意，-s 并不是包含性的，所以必须从所选择的开始时间中多减去十分钟。继续前面的示例，清单 4 显示了交换文件的使用情况和从第 22 天的 2:30 p.m. 到 3:00 p.m 的运行队列。

# sar -f /var/adm/sa/sa22 -s 14:20 -e 15:00 -w -q -i 4

SunOS unknown 5.10 Generic_118822-23 sun4u    01/22/2006

14:20:00 swpin/s bswin/s swpot/s bswot/s pswch/s
14:30:00    0.00     0.0    0.00     0.0     140
14:40:01    0.00     0.0    0.00     0.0     144
14:50:01    0.00     0.0    0.00     0.0     140
15:00:00    0.00     0.0    0.00     0.0     139

Average     0.00     0.0    0.00     0.0     140

14:20:00 runq-sz %runocc swpq-sz %swpocc
14:30:00    10.5     100     0.0       0
14:40:01    10.5     100     0.0       0
14:50:01    10.4     100     0.0       0
15:00:00    10.5     100     0.0       0

Average     10.5     100     0.0       0

回页首

了解它的所有含义

简单查看一下清单 4，它显示出交换活动为零，每秒大约发生 140 次进程切换，并且平均负载略高于 10。假设您当时正在调查较差性能的要求，那么从这些数据中可以得到什么结论呢？

• 因为没有发现交换过程，无论在运行什么进程，它们并没有消耗大量的内存。
• 该问题可能是由一组长时间运行的进程所导致，因为运行队列和进程切换相对稳定。如果以前并不是这样，那么可以怀疑是应用程序级的问题，如繁忙的 Web 服务器。
• 由于了解到清单 3 的输出显示了同一时间段的其他数据，您可以查看某块使用频繁的磁盘（根据 sar -b 为百分之 31，同时每秒 16,000 个盘块）。该磁盘是 home 目录分区，根据用户想要完成的任务不同，他/她可能会遇到较慢的响应。

快速查看该时间段内的 CPU 使用情况，显示出系统大约占用了百分之 80 的 CPU，剩下的用于用户任务。作为系统管理员，可以通过下面三种方式使用这一信息：

• 回到前几天的日志中。在本例中，我发现问题开始于 1:00 p.m.，并于第二天早上结束。
• 尝试将该活动与任何可能在该日开始的 cron 工作关联。
• 尝试找到其趋势。查看另外几天的数据，我发现性能是正常的，这并不表示系统已经达到其上限。

在本例中，看来已经将问题隔离出来了，出于该原因，我有意地使用 Shell 脚本来运转磁盘以创建一些有趣的 sar 报告！然而发现了一个趋势，如在工作时间内 home 驱动器比较繁忙，关于该问题可能存在完成某项任务的调用。可能的解决方案包括，将 home 目录拆分到其他磁盘、安装高速磁盘或将其转移到其他地方，如 Network Attached Storage (NAS)。

回页首

结束语

以周期性的间隔获取关于系统的定性数据，这是查找性能瓶颈并确定是否需要进一步操作的有效方法。可以使用 SAR 及其相关实用程序来完成这项任务，每隔十分钟获取一次快照并使用前端工具来访问这些数据。尽管实际上需要一定的策略，但系统管理员可以使用所提供的大量信息来发现系统中出现的问题，以及确定是否需要进行进一步的调查工作。