没有挫败，只有暂未成功而已。
2018年（28）
分类： 系统运维
2018-09-29 22:55:08
UNIX/Linux通用性能优化方法
优化方法总结：做系统性能优化，要遵循一些思想方法论。没有思想指导而茫然的动手操作，就如同黑夜里没有路灯而前进一样。针对一个应用系统的优化，有一些比较标准的流程，具体如下：
1. 获取基准数据
2. 压力测试和性能监视
3. 发现瓶颈所在
4. 优化，解决问题所在。
5. 重复（从第二个步骤开始）
UNIX/Linux通用性能监控：vmstat
接下来将讨论在所有UNIX分发版本（Solaris，HP-UX，Linux到AIX）上可用的UNIX通用工具。虽然有些输出内容根据分发版本不同而有所变化，但大多数标志适用于所有UNIX系统。这些标志可帮助动态地收集信息。
首先讨论vmstat。vmstat报告关于进程、内存、分页、被阻塞的I/O及总体CPU活动的信息。虽然这个工具与虚拟内存相关（vmstat中的vm），但在主机上运行vmstat可以快速而准确地确定服务器上发生的情况。
在遇到“为什么系统这么慢？”这种情况时，需要快速进行分析，以确定可能的瓶颈位置。vmstat是开始进行此工作的最好工具。
使用以下语法运行vmstat工具：
usage: vmstat [interval(s) [count]]
[root@dbsnc ~]# vmstat 1 10
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
2 0 9456 178272 0 1115180 0 0 88 25 153 200 1 0 98 1 0
1 0 9456 178260 0 1115212 0 0 0 0 280 425 0 0 100 0 0
0 0 9456 178228 0 1115272 0 0 0 0 427 610 1 0 99 0 0
0 0 9456 178228 0 1115272 0 0 0 44 229 358 0 0 100 0 0
1 0 9452 177980 0 1115276 32 0 32 14 538 898 0 1 99 0 0
1 0 9452 177980 0 1115276 0 0 0 0 228 357 0 0 100 0 0
1 0 9452 177980 0 1115276 0 0 0 32 340 531 0 0 100 0 0
1 0 9452 177732 0 1115276 0 0 0 0 380 542 1 0 99 0 0
0 0 9452 177732 0 1115276 0 0 0 0 438 637 0 0 100 0 0
1 0 9452 177732 0 1115276 0 0 0 32 467 658 0 0 100 0 0
procs 部分
r 表示运行队列(就是说多少个进程真的分配到CPU)，上面测试的服务器目前CPU比较空闲，没什么程序在跑，当这个值超过了CPU数目，就会出现CPU瓶颈了。这个也和top的负载有关系，一般负载超过了3就比较高，超过了5就高，超过了10就不正常了，服务器的状态很危险。top的负载类似每秒的运行队列。如果运行队列过大，表示你的CPU很繁忙，一般会造成CPU使用率很高。
b 表示阻塞的进程。
memory 部分
swpd 虚拟内存已使用的大小，如果大于0，表示你的机器物理内存不足了，如果不是程序内存泄露的原因，那么你该升级内存了或者把耗内存的任务迁移到其他机器。
free 空闲的物理内存的大小。
buff Linux/Unix系统是用来存储，目录里面有什么内容，权限等的缓存。
cache 直接用来记忆我们打开的文件,给文件做缓冲，把空闲的物理内存的一部分拿来做文件和目录的缓存，是为了提高程序执行的性能，当程序使用内存时，buffer/cached会很快地被使用。
swap 部分
si 每秒从磁盘读入虚拟内存的大小，如果这个值大于0，表示物理内存不够用或者内存泄露了，要查找耗内存进程解决掉。我的机器内存充裕，一切正常。
so 每秒虚拟内存写入磁盘的大小，如果这个值大于0，同上。
bi 块设备每秒接收的块数量，这里的块设备是指系统上所有的磁盘和其他块设备，默认块大小是1024byte，我本机上没什么IO操作，所以一直是0，但是我曾在处理拷贝大量数据(2-3T) 的机器上看过可以达到140000/s，磁盘写入速度差不多140M每秒
bo 块设备每秒发送的块数量，例如我们读取文件，bo就要大于0。bi和bo一般都要接近0，不然就是IO过于频繁，需要调整。
system 部分
in 每秒CPU的中断次数，包括时间中断
cs 每秒上下文切换次数，例如我们调用系统函数，就要进行上下文切换，线程的切换，也要进程上下文切换，这个值要越小越好，太大了，要考虑调低线程或者进程的数目,例如在apache和nginx这种web服务器中，我们一般做性能测试时会进行几千并发甚至几万并发的测试，选择web服务器的进程可以由进程或者线程的峰值一直下调，压测，直到cs到一个比较小的值，这个进程和线程数就是比较合适的值了。系统调用也是，每次调用系统函数，我们的代码就会进入内核空间，导致上下文切换，这个是很耗资源，也要尽量避免频繁调用系统函数。上下文切换次数过多表示你的CPU大部分浪费在上下文切换，导致CPU干正经事的时间少了，CPU没有充分利用，是不可取的。
cpu 部分
us 用户CPU时间，我曾经在一个做加密解密很频繁的服务器上，可以看到us接近100,r运行队列达到80(机器在做压力测试，性能表现不佳)。
sy 系统CPU时间，如果太高，表示系统调用时间长，例如是IO操作频繁。
id 空闲 CPU时间，一般来说，id + us + sy = 100,一般我认为id是空闲CPU使用率，us是用户CPU使用率，sy是系统CPU使用率。
wt 等待IO CPU时间。
Linux通用性能监控：
sar是UNIX System Activity Reporting工具。此命令已经成为了UNIX世界中永远存在的一员。此命令实际上就是将选择作为其标志的积累活动的内容写入到标准输出。例如使用-u标志报告CPU统计数据。
此命令的语法为：
[root@dbsnc ~]# sar --help
用法: sar [ 选项 ] [ <时间间隔> [ <次数> ] ]
选项:
[ -A ] [ -B ] [ -b ] [ -C ] [ -d ] [ -H ] [ -h ] [ -p ] [ -q ] [ -R ]
[ -r ] [ -S ] [ -t ] [ -u [ ALL ] ] [ -V ] [ -v ] [ -W ] [ -w ] [ -y ]
[ -I { <中断>
[,...] | SUM | ALL | XALL } ] [ -P {
[ -m { <关键词> [,...] | ALL } ] [ -n { <关键词> [,...] | ALL } ]
[ -j { ID | LABEL | PATH | UUID | ... } ]
[ -f [ <文件名> ] | -o [ <文件名> ] | -[0-9]+ ]
[ -i <间隔> ] [ -s [ <时:分:秒> ] ] [ -e [ <时:分:秒> ] ]
sar命令的选项很多，下面只列出常用选项：
? -u：CPU利用率
? -d：硬盘使用报告
? -b：缓冲区使用情况
? -w：系统交换活动。
[root@dbsnc ~]# sar -u
Linux 3.10.0-327.el7.x86_64 (dbsnc.local) 2018年09月29日 _x86_64_ (4 CPU)
14时18分33秒 LINUX RESTART
14时20分01秒 CPU %user %nice %system %iowait %steal %idle
14时30分01秒 all 5.50 0.00 0.66 4.16 0.00 89.68
14时40分01秒 all 0.71 0.00 0.19 0.13 0.00 98.97
14时50分01秒 all 0.69 0.00 0.17 0.02 0.00 99.11
15时00分01秒 all 0.63 0.00 0.17 0.01 0.00 99.19
15时10分01秒 all 0.62 0.00 0.16 0.01 0.00 99.20
15时20分01秒 all 0.87 0.01 0.24 0.09 0.00 98.79
? %usr cpu处在用户模式下时间
? %sys cpu处在系统模式下时间
? %wio cpu等待输入，输出完成时间
? %idle cpu空闲时间
[root@dbsnc ~]# sar -d 5
Linux 3.10.0-327.el7.x86_64 (dbsnc.local) 2018年09月29日 _x86_64_ (4 CPU)
17时34分53秒 DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util
17时34分58秒 dev8-0 1.59 0.00 25.50 16.00 0.00 0.12 0.12 0.02
17时34分58秒 dev11-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
17时34分58秒 dev253-0 1.59 0.00 25.50 16.00 0.00 0.12 0.12 0.02
17时34分58秒 dev253-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
? tps：平均每秒的读写请求合计次数
? rtps：平均每秒的读请求合计次数
? wtps：平均每秒的写请求合计次数
? bread/s：平均每秒从磁盘（或其它块设备）向系统buffer读的物理块数
? bwrtn/s：平均每秒从系统buffer向磁盘（或其它块设备）写的物理块数
[root@dbsnc ~]# sar -b
Linux 3.10.0-327.el7.x86_64 (dbsnc.local) 2018年09月29日 _x86_64_ (4 CPU)
14时18分33秒 LINUX RESTART
14时20分01秒 tps rtps wtps bread/s bwrtn/s
14时30分01秒 168.97 91.24 77.73 7753.75 1047.43
14时40分01秒 8.23 2.29 5.93 170.22 203.92
14时50分01秒 4.34 0.57 3.77 40.42 52.12
15时00分01秒 2.71 0.07 2.64 1.11 35.46
15时10分01秒 2.93 0.31 2.62 24.83 34.95
15时20分01秒 16.41 11.96 4.45 457.27 243.47
? rd_sec/s：每秒读的块数。每块512个字节
? wr_sec/s：每秒写的块数。每块512个字节
? avgrq-sz：平均每次读写操作的数量大小
? avgqu-sz：I/O队列的平均等待时间长度，单位毫秒
? %util：设备控制器繁忙百分比
CPU瓶颈表现在几个方面：
? 所有CPU都饱和
系统所有处理器都繁忙。根据vmstat和sar的报告，一般计算用户CPU时间和系统CPU时间。CPU利用率持续高于80%~85%之上就认为该环境的CPU资源使用过高
? 单个CPU饱和
系统在一个处理器上的负载达到了饱和，但其它处理器却部分或完全空闲。这通常发生在系统中只有一个很忙的应用程序在运行。虽然还有可用的CPU处理能力，
系统却无法使用，应用程序或语句的速度取决于这一个处理器内核的处理能力
? CPU异常空闲
如果运行环境的CPU资源突然出现使用率过低的情况（相比较正常情况而言），说明运行的应用可能也有性能问题，导致不能充分利用CPU资源
Linux通用性能监控：内存不足
内存引起的性能问题，一般来说，现象比较明显，处理起来也比较简单。内存资源常见的问题为内存资源不足。内存资源不足有两种，一是整体操作系统内存资源不足，无法满足新的内存分配需求；二是已分配给进程的内存资源不足，无法有效缓存数据降低I/O。当操作系统内存资源不足时，会发生Paging Space(或Swap空间)使用率过高的现象。UNIX使用虚拟内存技术，来分配和管理操作系统内存。这种管理方式
将虚拟内存分为Page。虚拟内存包括两部分，一部分是物理内存Page，另一部分是存储硬盘的映射Page。这两种类型Page的访问和运行速度是完全不一样的，相当于内存和硬盘的响应差别。简而言之，当进程使用的大量内存Page是存储硬盘映射时，运行速度会显著地变慢。观察内存资源的命令有vmstat、ps和svmon等等。目的是观察系统内存资源是否有足够剩余，观察进程使用的内存资源统计数据。
vmstat输出关注：fre-表示当前页面可用数量，pi/po(或si/so)-页面换入换出的数量。内存资源足够的一个现象是：fre列为较合理值并且pi/po(si/sw)的值很小或者为0。
Vmstat如果发现系统内存异常，可以通过ps或svmon(特定于AIX)查看内存：
可以用ps v选项或svmon -p选项查看特定进程的内存占用：
[root@dbsnc ~]# ps v
PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND
1264 tty1 Ss+ 0:00 1 30 109997 840 0.0 /sbin/agetty --noclear tty1 linux
3870 pts/0 Ss 0:00 1 882 115281 2812 0.1 -bash
5010 pts/0 R+ 0:00 0 89 137282 1280 0.0 ps v
ORACLE进程内存文本段，数据段和RSS内存等构成。并且，多次运行命令查看进程会随着工作量负载内存分配量会变化：
Linux通用性能监控：I/O瓶颈
操作系统磁盘I/O的一些性能指标包括：
? 吞吐量
硬盘传输数据流的速度，传输数据为读出和写入数据的和。单位一般为Kbps, MB/s等。
? 每秒I/O数(IOPS)
一次磁盘的连续读或者连续写，称为一次I/O。那么磁盘的IOPS就是每秒中磁盘连续读和连续写的和。
? 等待时间
指磁盘读或写操作等待执行的时间，即在队列中排队的时间。如果I/O请求持续超出磁盘的处理能力，那么来不及处理的请求将在队列中排队等候。
注：一个内存地址的操作大概会消耗500~600个CPU时钟周期；一个磁盘地址操作，大概需要20,000,000个CPU时钟周期，相当于40,000次内存操作。很多时候，数据库系统的瓶颈，往往出现在I/O层面。传统的基于磁盘的RDBMS中如何识别I/O的问题，就变得很重要。
主要关注sar -d命令几个列的数值即可，分别是：
? %busy：如果磁盘使用率长时间达到75%或80%, 说明该磁盘较忙
? avwait：磁盘读或写操作等待执行的平均时间（单位为毫秒）
? avserv：磁盘读或写操作所执行的平均时间（单位为毫秒）
当avque数值过高时，可能表示多个进程正在竞争使用该磁盘。高avserv值表示磁盘的速度较慢。
解决I/O性能问题需要磁盘、存储等方面的性能优化。主要考虑以下事项：
? 尽可能减少不必要的I/O操作
在保证完成业务操作的前提下，尽可能将应用的I/O操作降低到最低水平，如合理使用索引技术
? I/O分布均衡
尽量将I/O的请求合理地分布在所用到的所有物理磁盘上。
? RAID
使用RAID时，尽量使应用程序I/O等于条带尺寸或者为条带尺寸的倍数。并选取合适的RAID方式，如RAID10，RAID5等等。
? I/O缓存
应用I/O缓存技术，减少直接对磁盘的I/O数量。可以在应用程序层面进行缓存处理，也可以在文件系统层面进行缓存设置（参考vmtune说明）。
? 数据CACHE
利用内存读写访问比磁盘访问优越的特点，将应用程序读写频繁的文件或者数据，放置在内存中进行cache，减少磁盘I/O操作，提高整体性能。
Linux通用性能监控：网络问题
在一些基于网络通信的客户机/服务器系统场景下，需要注意网络引起的性能问题。常见的网络性能问题主要表现在传输不稳定、丢包或者网卡传输速率达到饱和，造成网络消息排队等等。
在UNIX/Linux系统上提供了工具来进行网络监控。一些用来实时诊断，另外一些可以显示网络数据的历史趋势和分析数据。常用的判断网络性能问题的命令有ping、netstat。
? ping命令主要用来检查网络的连通性
从ping的结果可以检查网络的质量、丢包率等。time值可以用来判断网络传送延时情况，局域网中（大多数为万兆卡光纤连接），time值应该为0。
通常在UNIX或Linux中ping加选项-s，指定包大小，通常建议65500
通常在Windows中ping加选项-l，指定包大小，通常建议65500
UNIX和Linux指定大包ping：
[root@dbsnc ~]# ping 192.168.10.65 -s 65500
PING 192.168.10.65 (192.168.10.65) 65500(65528) bytes of data.
65508 bytes from 192.168.10.65: icmp_seq=1 ttl=128 time=2.86 ms
65508 bytes from 192.168.10.65: icmp_seq=2 ttl=128 time=2.29 ms
65508 bytes from 192.168.10.65: icmp_seq=3 ttl=128 time=2.98 ms
65508 bytes from 192.168.10.65: icmp_seq=4 ttl=128 time=3.30 ms
Windows指定大包ping：
C:\Users\weiju>ping -l 65500 192.168.10.222
正在 Ping 192.168.10.222 具有 65500 字节的数据:
来自 192.168.10.222 的回复: 字节=65500 时间=1ms TTL=64
来自 192.168.10.222 的回复: 字节=65500 时间=2ms TTL=64
来自 192.168.10.222 的回复: 字节=65500 时间=4ms TTL=64
来自 192.168.10.222 的回复: 字节=65500 时间=2ms TTL=64
netstat对网络运行进行统计观察。netstat常用的参数有-in/-an/等等。
使用-in选项时
? Ierrs表示接收失败的总包数
? Oerrs表示发送失败的总包数
? 检查Ierrs/Ipkts超过1%或Oerrs/Opkts超过1%时，可能网络不稳定当使用-an选项时
? Recv-Q表示接收网卡队列的排队情况
? Send-Q表示网卡发送队列的排队情况
? state表示网络连接的状态，一般为LISTEN或ESTABLISH。出现类似LAST_ACK、FIN_WAIT之类的状态时说明TCP连接质量比较差，如果该TCP连接是应用程序所使用，那么需要引起注意
Linux通用性能监控：nmon
nmon工具可以为AIX和Linux性能专家提供监视和分析性能数据的功能，其中包括：
? CPU使用率
? 内存使用情况
? 内核统计信息和运行队列信息
? 磁盘I/O速度、传输和读/写比率
? 文件系统中的可用空间
? 网络I/O速度、传输和读/写比率
? 页面空间和页面速度
? 消耗资源最多的进程
? 计算机详细信息和资源
? 异步I/O，仅适用于AIX
? 网络文件系统(NFS)
? 交互式的方式运行
运行该工具，阅读该文件前页中的相关提示。并使用单键命令来查看所需要的数据。例如，
要获取CPU、内存和磁盘统计信息，启动nmon并输入：cmd
? 附加帮助信息
要获取附加的帮助信息，可以尝试下列方法：
– 输入nmon -?命令以获取简短的详细信息。
– 输入nmon -h命令以获取完整的详细信息。
– 阅读自述文件。
? 将数据捕获到文件
运行带-f标志的nmon命令按时间间隔捕获数据快照：
带-T标志的命令捕获消耗资源最多的进程。这两行命令都将在-m指定的目录中创建输出文件，其名称为：
nmon_analyser工具可以帮助对通过nmon性能工具捕获的性能数据进行分析。将输出中的每个主要部分自动地生成相应的图形。完成下列任务：
? 以电子表格的形式查看相应的数据
? 消除‘错误的’数据
? 生成向客户进行演示的图形
工具将对nmon数据进行分析以生成下列信息：
? 热点分析维度的加权平均值的计算
? 用处理器与收集间隔的比值表示的CPU使用率的分布情况
? 每日各时段的系统总数据速率，识别I/O子系统和SAN（存储局域网络）瓶颈
? 分析内存使用率，以显示计算性和非计算性页面之间的差异
? 每个网络适配器的每日各时段总数据速率
? 显示平均CPU和内存使用率的TOP进程部分汇总数据
获取该工具nmon_analyzer：
https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Power%20Systems/page/nmon_analyser
获取nmon for AIX：
https://www.ibm.com/developerworks/community/wikis/home?lang=en#/wiki/Power%20Systems/page/nmon
获取nmon for Linux：nmon.sourceforge.net
ORACLE性能：AWR 报表
必需阅读的AWR报表重要内容列表：
? AWR报表概览
? 主机和实例的CPU使用情况
? 主机内存使用情况
? 主机I/O性能情况
? 操作性能统计信息
? 分析Top 5 Timed Events
? 查看和顶级等待事件有关的Load profile内容
AWR 报表：报告概览
? 数据库信息：数据库名，DBID，实例名，实例号，版本信息，是否为RAC
? 主机环境：数据库运行的主机环境信息
? AWR报告快照信息：包括报告的快照跨度，挂钟时间和数据库时间，会话数等
数据库负载：平均活动会话数 =DB time/Elapsed=1695.61/30.14=56.27
1,695.61/30.14
|
DB Name |
DB Id |
Instance |
Inst num |
Startup Time |
Release |
RAC |
|
DBSVC |
XXXXXXXCCC |
DBSVC1 |
3 |
28-Mar-18 23:03 |
11.2.0.4.0 |
YES |
|
Host Name |
Platform |
CPUs |
Cores |
Sockets |
Memory (GB) |
|
SVC1 |
Linux x86 64-bit |
240 |
120 |
8 |
2019.48 |
|
Snap Id |
Snap Time |
Sessions |
Cursors/Session |
Instances |
|
|
Begin Snap: |
45483 |
19-Sep-18 02:00:21 |
14007 |
2.2 |
3 |
|
End Snap: |
45484 |
19-Sep-18 02:30:29 |
14008 |
2.2 |
3 |
|
Elapsed: |
|
30.14 (mins) |
|
|
|
|
DB Time: |
|
1,695.61 (mins) |
|
|
|
AWR 报表：主机和实例的CPU
? 从操作系统维度统计CPU的时间片统计信息
– 用户占用
– 系统占用
– I/O等待
– 空闲
? 从实例维度统计CPU使用率
– 实例消耗所有CPU比例，占OS维度消CPU比例和DB Time中等待CPU资源时间比例
Host CPU
|
CPUs |
Cores |
Sockets |
Load Average Begin |
Load Average End |
%User |
%System |
%WIO |
%Idle |
|
240 |
120 |
8 |
19.69 |
27.13 |
5.7 |
3.3 |
1.5 |
90.4 |
Instance CPU
|
%Total CPU |
%Busy CPU |
%DB time waiting for CPU (Resource Manager) |
|
6.9 |
72.1 |
0.0 |
AWR 报表：主机内存使用
实例已分配内存，包括系统全局区，程序全局区（SQL工作区和堆栈空间、用户全局区等）；实例已分配系统内存所占比例。
注：程序全局区中并不包括创建服务器进程数据段之外的其他内存段
Memory Statistics
|
Begin |
End |
|
|
Host Mem (MB): |
2,067,942.6 |
2,067,942.6 |
|
SGA use (MB): |
805,858.3 |
805,858.3 |
|
PGA use (MB): |
48,756.5 |
52,354.2 |
|
% Host Mem used for SGA+PGA: |
41.33 |
41.50 |
Cache Sizes
|
Begin |
End |
|||
|
Buffer Cache: |
604,160M |
604,160M |
Std Block Size: |
8K |
|
Shared Pool Size: |
93,697M |
93,701M |
Log Buffer: |
556,692K |
AWR 报表：主机I/O性能
读，写(reads，Writes)频繁的表空间的Av Rd(ms)和Av Buf Wt(ms)小于20ms说明I/O设备性能良好。超过此阀值数据库整体性能可能产生明下降。
Tablespace IO Stats
|
Tablespace |
Reads |
Av Rds/s |
Av Rd(ms) |
Av Blks/Rd |
1-bk Rds/s |
Av 1-bk Rd(ms) |
Writes |
Writes avg/s |
Av Writes(ms) |
Buffer Waits |
Av Buf Wt(ms) |
|
DDD_SVC_02 |
5,406,702 |
2,990 |
0.91 |
1.93 |
1,384,091 |
1958.53 |
1 |
765 |
2.98 |
9,329,239 |
0.89 |
|
DDD_SVC_01 |
620,657 |
343 |
0.83 |
1.75 |
1,198 |
323.42 |
1 |
1 |
0.29 |
2,277 |
67.51 |
|
DDD_SSD_LOCAL |
254,168 |
141 |
1.25 |
1.00 |
709 |
140.55 |
1 |
0 |
0.92 |
1,041 |
2.78 |
|
UNDOTBS3 |
279 |
0 |
1.04 |
1.00 |
27,783 |
0.15 |
1 |
15 |
1.30 |
738 |
28.94 |
|
TEMP_SVC |
6,151 |
3 |
0.00 |
16.58 |
11,624 |
0.01 |
0 |
6 |
0.00 |
0 |
0.00 |
|
DDD_PARA |
1,993 |
1 |
1.18 |
1.05 |
8,322 |
1.09 |
1 |
5 |
0.90 |
1,535 |
17.53 |
|
SYSTEM |
1,807 |
1 |
1.43 |
2.40 |
183 |
0.34 |
2 |
0 |
0.60 |
1 |
0.00 |
|
SYSAUX |
717 |
0 |
2.05 |
1.00 |
673 |
0.40 |
2 |
0 |
0.94 |
0 |
0.00 |
|
WORK_A |
140 |
0 |
0.00 |
1.00 |
838 |
0.08 |
0 |
0 |
0.78 |
0 |
0.00 |
|
UNDOTBS1 |
284 |
0 |
1.37 |
1.00 |
24 |
0.16 |
1 |
0 |
0.00 |
5 |
0.00 |
AWR 报表：操作性能统计信息
按统计信息类型排序(CPU使用，虚拟内存，硬件配置)用于回顾快照期间操作系统的性能数据概况
· *TIME statistic values are diffed. All others display actual values. End Value is displayed if different
· ordered by statistic type (CPU Use, Virtual Memory, Hardware Config), Name
|
Statistic |
Value |
End Value |
|
BUSY_TIME |
4,110,054 |
|
|
IDLE_TIME |
38,649,973 |
|
|
IOWAIT_TIME |
634,433 |
|
|
NICE_TIME |
0 |
|
|
SYS_TIME |
1,405,709 |
|
|
USER_TIME |
2,448,816 |
|
|
LOAD |
20 |
27 |
|
PHYSICAL_MEMORY_BYTES |
2,168,394,989,568 |
|
|
NUM_CPUS |
240 |
|
|
NUM_CPU_CORES |
120 |
|
|
NUM_CPU_SOCKETS |
8 |
|
|
GLOBAL_RECEIVE_SIZE_MAX |
4,194,304 |
|
|
GLOBAL_SEND_SIZE_MAX |
1,048,576 |
|
|
TCP_RECEIVE_SIZE_DEFAULT |
87,380 |
|
|
TCP_RECEIVE_SIZE_MAX |
4,194,304 |
|
|
TCP_RECEIVE_SIZE_MIN |
4,096 |
|
|
TCP_SEND_SIZE_DEFAULT |
16,384 |
|
|
TCP_SEND_SIZE_MAX |
4,194,304 |
|
|
TCP_SEND_SIZE_MIN |
4,096 |
|
AWR 报表： Top 10 Foreground Events by Total Wait Time
分析Top 10 Foreground Events by Total Wait Time的意义：
? 评估等待事件(包括DB CPU，CPU Time部分)对性能产生的影响程度
? 评估已定义的问题域发生在数据库环境内部（整个服务器环境）或外部（服务器环境之外）
如确定问题域在数据库环境内部，通过分析等待事件快速定位问题诊断方向：
? DB CPU，CPU Time评估主机的CPU使用率
? 确定等待事件优先域，结合My Oracle Support给出的诊断方法进一步分析
阅读AWR报告首先关注Wait Class，优先确认是否有”Concurrency”类型的等待事件。如果有类型为“Concurrency”的等待事件，并且数据库不空闲时通常就可以直接确定数据库有性能问题。否则，按Wait Class进行分类分析，使确定“数据库是否存在性能问题”变得相对容易，此例中，存在着Cluster、Commit和Application这三类资源的等待事件。
Top 10 Foreground Events by Total Wait Time
|
Event |
Waits |
Total Wait Time (sec) |
Wait Avg(ms) |
% DB time |
Wait Class |
|
DB CPU |
|
25.7K |
|
25.3 |
|
|
gc buffer busy acquire |
7,132,439 |
6762.1 |
1 |
6.6 |
Cluster |
|
log file sync |
600,395 |
6076 |
10 |
6.0 |
Commit |
|
db file sequential read |
3,941,975 |
4426.1 |
1 |
4.4 |
User I/O |
|
gc cr multi block request |
2,122,604 |
2110.4 |
1 |
2.1 |
Cluster |
|
gc cr grant 2-way |
2,317,902 |
1618.3 |
1 |
1.6 |
Cluster |
|
read by other session |
1,219,631 |
1347.9 |
1 |
1.3 |
User I/O |
|
db file scattered read |
1,902,151 |
1337.9 |
1 |
1.3 |
User I/O |
|
gc current block 2-way |
1,233,737 |
967 |
1 |
1.0 |
Cluster |
|
library cache: mutex X |
1,001,569 |
707.8 |
1 |
.7 |
Concurrency |
接下来还要结合系统负载情况分析。单纯分析等待事件是没有太大意义的。首先，通过平均活动会话数为：DB Time/Elapsed，说明一小时内约为56进程一直在忙，说明数据库不空闲。从Wait Class中有”Concurrency”类型的等待事件。可以直接确定数据库有性能问题。顺理成章地，减少latch: cache buffers chains等事件的时间就成了优化要解决的重点方向。
注：在并行指令流水CPU的环境中，平均活动会话数可能大大超过物理CPU数量。
AWR报表：确定问题域分析示例
集群数据库实例间会互相产生影响，所以，还需要另外实例同一时间的AWR报表来分析，确定：
? 其他实例是否在同时段也呈现相同的等待事件和类似的计量
? 等待事件的诊断方法很可能需要DBA关注其他实例同时估的报告
经分析：平均活动会话数为56，数据库有240CPU，资源未出现瓶颈，但数据库不空闲。Wait Class没有Concurrency类型的等待，只有Cluster、Commit和Application这三类资源的等待事件。 Cluster等待占11%的DB Time为首要关注的事件，而Commit占6%，可以忽视。仅从DBTime的比例还不能确定数据库是否存在性能问题。
通过上述的分析，得到了分析Top 10 Timed Events必须要明确获得的答案：性能问题是否在数据库环境中？
答案是：性能问题在数据库环境中。那么，确定数据库有性能问题的依据就成为要首要优化的性能问题。但是，在这个例子中，存在两个需要去解决的问题，一类是Cluster，另一类是Commit。这是两类资源的等待事件，真正的原因还待分析。但至少确定了两个诊断重点方向。这两类等待是否互相影响？哪类是更重要的问题？重要的性能问题要更优先解决！是否能从确定数据库有性能问题的多类等待中找出重点，减少问题诊断的工作量和时间，减少优化工作需要投入的成本？这些问题是接下来要重点思考的。等待事件的定义：某种场景下进程必须等待要操作的某类资源准备就绪。按OWI知识体系，可以了解Cluster和Commit类的等待事件是在什么场景下等待哪类资源就绪。根据计算机体系统结构和对设备性能期望的不同，解决问题优先顺序是：并行处理(Oracle产品定位)、内存(速度最快期望最高)、磁盘I/O(DB的基础资源)、应用(直接反馈性能问题)、网络(请求送达或已处理数据传递)、Other(不太好确定，视具体情形)。
