http://www.quke.org/log-424.html

在使用了xen以后发现开机后内存直接占了一半，似乎不正常，就查找了些linux内存方面的资料。

我们一开始，先从Free命令说起。
free 命令相对于top 提供了更简洁的查看系统内存使用情况：

[/root]free 
             total       used       free     shared    buffers     cached 
Mem:        542668     263680     278988          0      66408      93168 
-/+ buffers/cache:     104104     438564 
Swap:      1048568          0    1048568 
[/root] 

Mem：表示物理内存统计 
-/+ buffers/cached：表示物理内存的缓存统计 
Swap：表示硬盘上交换分区的使用情况，这里我们不去关心。
系统的总物理内存：542668Kb（512M），但系统当前真正可用的内存并不是第一行free 标记的 278988Kb，它仅代表未被分配的内存。
我们使用total1、used1、free1、used2、free2 等名称来代表上面统计数据的各值，1、2 分别代表第一行和第二行的数据。
total1：表示物理内存总量。 
used1：表示总计分配给缓存（包含buffers 与cache ）使用的数量，但其中可能部分缓存并未实际使用。 
free1：未被分配的内存。 
shared1：共享内存，一般系统不会用到，这里也不讨论。 
buffers1：系统分配但未被使用的buffers 数量。 
cached1：系统分配但未被使用的cache 数量。buffer 与cache 的区别见后面。 
used2：实际使用的buffers 与cache 总量，也是实际使用的内存总量。 
free2：未被使用的buffers 与cache 和未被分配的内存之和，这就是系统当前实际可用内存。
可以整理出如下等式：
total1 = used1 + free1

total1 = used2 + free2

used1 = buffers1 + cached1 + used2

free2 = buffers1 + cached1 + free1
buffer 与cache 的区别
A buffer is something that has yet to be "written" to disk. A cache is something that has been "read" from the disk and stored for later use.
更详细的解释参考：Difference Between Buffer and Cache
对于共享内存（Shared memory），主要用于在UNIX 环境下不同进程之间共享数据，是进程间通信的一种方法，一般的应用程序不会申请使用共享内存，笔者也没有去验证共享内存对上面等式的影响。如果你有兴趣，请参考：What is Shared Memory?
cache 和 buffer的区别：
Cache：高速缓存，是位于CPU与主内存间的一种容量较小但速度很高的存储器。由于CPU的速度远高于主内存，CPU直接从内存中存取数据要等待一定时间周期，Cache中保存着CPU刚用过或循环使用的一部分数据，当CPU再次使用该部分数据时可从Cache中直接调用,这样就减少了CPU的等待时间,提高了系统的效率。Cache又分为一级Cache(L1 Cache)和二级Cache(L2 Cache)，L1 Cache集成在CPU内部，L2 Cache早期一般是焊在主板上,现在也都集成在CPU内部，常见的容量有256KB或512KB L2 Cache。
Buffer：缓冲区，一个用于存储速度不同步的设备或优先级不同的设备之间传输数据的区域。通过缓冲区，可以使进程之间的相互等待变少，从而使从速度慢的设备读入数据时，速度快的设备的操作进程不发生间断。
Free中的buffer和cache：（它们都是占用内存）：
buffer : 作为buffer cache的内存，是块设备的读写缓冲区
cache: 作为page cache的内存, 文件系统的cache
如果 cache 的值很大，说明cache住的文件数很多。如果频繁访问到的文件都能被cache住，那么磁盘的读IO 必会非常小。

总结如下：

linux内存分配出去了，但是可能并没实际使用。

本文转载自三少的学习笔记　　

按照OracleOnlineBook中的描述，v$sesstat存储session从login到logout的详细资源使用统计。

类似于v$sysstat,该视图存储下列类别的统计：

l         事件发生次数的统计，如用户提交数。

l         数据产生，存取或者操作的total列(如：redo size)

l         执行操作所花费的时间累积，例如session CPU占用(如果TIMED_STATISTICS值为true)

注意：

如果初始参数STATISTICS_LEVEL被设置为TYPICAL或ALL，时间统计被数据库自动收集如果STATISTICS_LEVEL被设置为BASIC，你必须设置TIMED_STATISTICS值为TRUE以打开收集功能。

如果你已设置了DB_CACHE_ADVICE,TIMED_STATISTICS或TIMED_OS_STATISTICS，或在初始参数文件或使用ALTER_SYSTEM或ALTER SESSION，那么你所设定的值的值将覆盖STATISTICS_LEVEL的值。

v$sysstat和v$sesstat差别如下：

n         v$sesstat只保存session数据，而v$sysstat则保存所有sessions的累积值。

n         v$sesstat只是暂存数据，session退出后数据即清空。v$sysstat则是累积的，只有当实例被shutdown才会清空。

n         v$sesstat不包括统计项名称，如果要获得统计项名称则必须与v$sysstat或v$statname连接查询获得。

v$sesstat可被用于找出如下类型session：

n         高资源占用

n         高平均资源占用比(登陆后资源使用率)

n         默认资源占用比(两快照之间)

在V$SESSTAT中使用统计

　　多数v$sesstat中的统计参考是v$sysstat描述的子集，包括session logical reads, CPU used by this session, db block changes, redo size, physical writes, parse count (hard), parse count (total), sorts (memory), and sorts (disk).

V$SESSTAT常用列说明

n         SID：session唯一ID

n         STATISTIC#：资源唯一ID

n         VALUE：资源使用

示例1：下列找出当前session中最高的logical和Physical I/O比率.

　　下列SQL语句显示了所有连接到数据库的session逻辑、物理读比率(每秒)。logical和physical I/O比率是通过自登陆后的时间消耗计算得出。对于sessions连接到数据库这种长周期操作而言也许不够精确，不过做个示例却足够了。

先获得session逻辑读和物理读统计项的STATISTIC#值：

SELECT name, statistic#

  FROM V$STATNAME

  WHERE name IN ('session logical reads','physical reads') ;

NAME                           STATISTIC#

------------------------------ ----------

session logical reads                   9

physical reads                        54

通过上面获得的STATISTIC#值执行下列语句：

SELECT ses.sid

     , DECODE(ses.action,NULL,'online','batch')          "User"

     , MAX(DECODE(sta.statistic#,9,sta.value,0))

       /greatest(3600*24*(sysdate-ses.logon_time),1)     "Log IO/s"

     , MAX(DECODE(sta.statistic#,54,sta.value,0))

       /greatest(3600*24*(sysdate-ses.logon_time),1)     "Phy IO/s"

     , 60*24*(sysdate-ses.logon_time)                    "Minutes"

 FROM V$SESSION ses

    , V$SESSTAT sta

WHERE ses.status     = 'ACTIVE'

  AND sta.sid        = ses.sid

  AND sta.statistic# IN (9,54)

GROUP BY ses.sid, ses.action, ses.logon_time  <== 先按sid分组，再按action分组，最后按登录时间分组

ORDER BY

        SUM( DECODE(sta.statistic#,54,100*sta.value,sta.value) )

      / greatest(3600*24*(sysdate-ses.logon_time),1)  DESC;

  SID User   Log IO/s Phy IO/s Minutes

----- ------ -------- -------- -------

 1951 batch       291    257.3       1

  470 online    6,161     62.9       0

  730 batch     7,568     43.2     197

 2153 online    1,482     98.9      10

 2386 batch     7,620     35.6      35

 1815 batch     7,503     35.5      26

 1965 online    4,879     42.9      19

 1668 online    4,318     44.5       1

 1142 online      955     69.2      35

 1855 batch       573     70.5       8

 1971 online    1,138     56.6       1

 1323 online    3,263     32.4       5

 1479 batch     2,857     35.1       3

  421 online    1,322     46.8      15

 2405 online      258     50.4       8

Tips:

Ø         DECODE函数

语法：DECODE(条件表达式，值，返回值1，返回值2)

解释：当“条件表达式”计算出来的结果等于“值”，那么返回“返回值1”否则返回“返回值2”

Ø         MAX函数可以返回一组数值中的最大值，忽略逻辑值和文本字符

Ø         greatest( expr1, expr2, ... expr_n )

expr1, expr2, . expr_n 可以值也可以是函数.

函数功能：  取得值最大值。

影响版本:Oracle 8i, Oracle 9i, Oracle 10g, Oracle 11g

例子:

greatest(2, 5, 12, 3) would return 12

greatest('2', '5', '12', '3') would return '5'

greatest('apples', 'oranges', 'bananas') would return 'oranges'

greatest('apples', 'applis', 'applas') would return 'applis'

示例2：又例如通过v$sesstat和v$statname连接查询某个SID各项信息。

select a.*,b.name

  from v$sesstat a,v$statname b

  where a.sid=164 and a.statistic#=b.statistic#;

group by 的用法：

http://bkeep.blog.163.com/blog/static/1234142902010220104316786

http://bkeep.blog.163.com/blog/static/1234142902010220104140682

一，类似于V$SESSTAT，该视图存储下列的统计信息： 1
1>.事件发生次数的统计(如：user commits) 1
2>.数据产生，存取或者操作的total列(如：redo size) 1
3>.如果TIMED_STATISTICS值为true,则统计花费在执行操作上的总时间(如：CPU used by this session) 1
二，V$SYSSTAT视图常用列介绍： 1
该视图还有一列class-统计类别但极少会被使用，各类信息如下： 1
三，使用V$SYSSTAT中的数据 2
3.1 v$sysstat功能概述 2
3.2数据库使用状态的一些关键指标： 2
3.3 SQL语句解析过程 3
3.4 物理I/O 3
四，V$SYSSTAT典型应用 3
4.1由V$SYSSTAT得出实例效率比(Instance Efficiency Ratios) 3
4.2 Buffer cache hit ratio：该项显示buffer cache大小是否合适。 3
4.3 Soft parse ratio：这项将显示系统是否有太多硬解析。 3
4.4 In-memory sort ratio：该项显示内存中完成的排序所占比例。 4
4.5 Parse to execute ratio：在生产环境，最理想状态是一条sql语句一次解析多数运行。 4
4.6 Parse CPU to total CPU ratio：该项显示总的CPU花费在执行及解析上的比率。 4
4.7 Parse time CPU to parse time elapsed：通常，该项显示锁竞争比率。 4
五，从V$SYSSTAT获取负载间档(LOAD PROFILE)数据 4
5.0 概述 4
5.2 Blocks changed for each read：这项显示出block changes在block reads中的比例。 5
5.3 Rows for each sort： 5

正文：

文档下载：http://www.itpub.net/782892.html

v$sysstat存储自数据库实例运行起就开始累计全实例(instance-wide)的资源使用情况。

一，类似于v$sesstat，该视图存储下列的统计信息：

1>.事件发生次数的统计(如：user commits)

2>.数据产生，存取或者操作的total列(如：redo size)

3>.如果TIMED_STATISTICS值为true,则统计花费在执行操作上的总时间(如：CPU used by this session)

二，v$sysstat视图常用列介绍：

STATISTIC#: 标识
NAME: 统计项名称
VALUE: 资源使用量

该视图还有一列class-统计类别但极少会被使用，各类信息如下：

1 代表事例活动
2 代表Redo buffer活动
4 代表锁
8 代表数据缓冲活动
16 代表OS活动
32 代表并行活动
64 代表表访问
128 代表调试信息
注意：Statistic#的值在不同版本中各不相同，使用时要用Name做为查询条件而不要以statistic#的值做为条件。

三，使用v$sysstat中的数据

3.1 v$sysstat功能概述

　　该视图中数据常被用于监控系统性能。如buffer cache命中率、软解析率等都可从该视图数据计算得出。
　　该视图中的数据也被用于监控系统资源使用情况，以及系统资源利用率的变化。正因如此多的性能数据，检查某区间内系统资源使用情况可以这样做，在一个时间段开始时创建一个视图数据快照，结束时再创建一个，二者之间各统计项值的不同(end value - begin value)即是这一时间段内的资源消耗情况。这是oracle工具的常用方法，诸如Statspack以及BSTAT/ESTAT都是如此。
　　为了对比某个区间段的数据，源数据可以被格式化（每次事务，每次执行，每秒钟或每次登陆），格式化后数据更容易从两者中鉴别出差异。这类的对比在升级前，升级后或仅仅想看看一段时间内用户数量增长或数据增加如何影响资源使用方面更加实用。
　　你也可以使用v$sysstat数据通过查询v$system_event视图来检查资源消耗和资源回收。

V$SYSSTAT中的常用统计

　　V$SYSSTAT中包含多个统计项，这部分介绍了一些关键的v$sysstat统计项，在调优方面相当有用。下列按字母先后排序：

3.2数据库使用状态的一些关键指标：

CPU used by this session：所有session的cpu占用量，不包括后台进程。这项统计的单位是百分之x秒.完全调用一次不超过10ms
db block changes：那部分造成SGA中数据块变化的insert,update或delete操作数 这项统计可以大概看出整体数据库状态。在各项事务级别，这项统计指出脏缓存比率。单位是：块
execute count：执行的sql语句数量(包括递归sql)
logons current：当前连接到实例的Sessions。如果当前有两个快照则取平均值。
logons cumulative：自实例启动后的总登陆次数。
parse count (hard)：在shared pool中解析调用的未命中次数。当sql语句执行并且该语句不在shared pool或虽然在shared pool但因为两者存在部分差异而不能被使用时产生硬解析。如果一条sql语句原文与当前存在的相同，但查询表不同则认为它们是两条不同语句，则硬解析即会发生。硬解析会带来cpu和资源使用的高昂开销，因为它需要oracle在shared pool中重新分配内存，然后再确定执行计划，最终语句才会被执行。单位：解析次数
parse count (total)：解析调用总数，包括软解析和硬解析。当session执行了一条sql语句，该语句已经存在于shared pool并且可以被使用则产生软解析。当语句被使用(即共享) 所有数据相关的现有sql语句(如最优化的执行计划)必须同样适用于当前的声明。这两项统计可被用于计算软解析命中率。单位：解析次数
parse time cpu：总cpu解析时间(单位：10ms)。包括硬解析和软解析。
parse time elapsed：完成解析调用的总时间花费。
physical reads：OS blocks read数。包括插入到SGA缓存区的物理读以及PGA中的直读这项统计并非i/o请求数。

单位：OS blocks
physical writes：从SGA缓存区被DBWR写到磁盘的数据块以及PGA进程直写的数据块数量。单位：数据块
redo log space requests：在redo logs中服务进程的等待空间，表示需要更长时间的log switch。
redo size：redo发生的总次数(以及因此写入log buffer)，以byte为单位。这项统计显示出update活跃性。
session logical reads：逻辑读请求数。
sorts (memory) ：sorts(memory)是适于在SORT_AREA_SIZE(因此不需要在磁盘进行排序)的排序操作的数量。

sorts (disk)：sorts(disk)则是由于排序所需空间太大，SORT_AREA_SIZE不能满足而不得不在磁盘进行排序操作的数量。这两项统计通常用于计算in-memory sort ratio。
sorts (rows): 列排序总数。这项统计可被'sorts (total)'统计项除尽以确定每次排序的列。该项可指出数据卷和应用特征。
table fetch by rowid：使用ROWID返回的总列数(由于索引访问或sql语句中使用了'where rowid=&rowid'而产生)
table scans rows gotten：全表扫描中读取的总列数
table scans blocks gotten：全表扫描中读取的总块数，不包括那些split的列。
user commits + user rollbacks：系统事务起用次数。当需要计算其它统计中每项事务比率时该项可以被做为除数。例如，计算事务中逻辑读，可以使用下列公式：session logical reads / (user commits + user rollbacks)。

3.3 SQL语句解析过程

注：SQL语句的解析有软解析soft parse与硬解析hard parse之说，以下是5个步骤：
1：语法是否合法(sql写法)
2：语义是否合法(权限，对象是否存在)
3：检查该sql是否在公享池中存在
-- 如果存在,直接跳过4和5,运行sql. 此时算soft parse
4：选择执行计划
5：产生执行计划
-- 如果5个步骤全做,这就叫hard parse.

3.4 物理I/O

注：注意物理I/O

　　oracle报告物理读也许并未导致实际物理磁盘I/O操作。这完全有可能因为多数操作系统都有缓存文件，可能是那些块在被读取。块也可能存于磁盘或控制级缓存以再次避免实际I/O。Oracle报告有物理读也许仅仅表示被请求的块并不在缓存中。

四，V$SYSSTAT典型应用

4.1由V$SYSSTAT得出实例效率比(Instance Efficiency Ratios)

下列是些典型的instance efficiency ratios 由v$sysstat数据计算得来，每项比率值应该尽可能接近1：

4.2 Buffer cache hit ratio：该项显示buffer cache大小是否合适。

公式：1-((physical reads-physical reads direct-physical reads direct (lob)) / session logical reads)
执行：
select 1-((a.value-b.value-c.value)/d.value)
from v$sysstat a,v$sysstat b,v$sysstat c,v$sysstat d
where a.name='physical reads' and
b.name='physical reads direct' and
c.name='physical reads direct (lob)' and
d.name='session logical reads';

4.3 Soft parse ratio：这项将显示系统是否有太多硬解析。

该值将会与原始统计数据对比以确保精确。例如，软解析率仅为0.2则表示硬解析率太高。不过，如果总解析量(parse count total)偏低，这项值可以被忽略。
公式：1 - ( parse count (hard) / parse count (total) )
执行：
select 1-(a.value/b.value)
from v$sysstat a,v$sysstat b
Where a.name='parse count (hard)' and b.name='parse count (total)';

4.4 In-memory sort ratio：该项显示内存中完成的排序所占比例。

最理想状态下，在OLTP系统中，大部分排序不仅小并且能够完全在内存里完成排序。
公式：sorts (memory) / ( sorts (memory) + sorts (disk) )
执行：
select a.value/(b.value+c.value)
from v$sysstat a,v$sysstat b,v$sysstat c
where a.name='sorts (memory)' and
b.name='sorts (memory)' and c.name='sorts (disk)';

4.5 Parse to execute ratio：在生产环境，最理想状态是一条sql语句一次解析多数运行。

公式：1 - (parse count/execute count)
执行：
select 1-(a.value/b.value)
from v$sysstat a,v$sysstat b
where a.name='parse count (total)' and b.name='execute count';

4.6 Parse CPU to total CPU ratio：该项显示总的CPU花费在执行及解析上的比率。

如果这项比率较低，说明系统执行了太多的解析。
公式：1 - (parse time cpu / CPU used by this session)
执行：
select 1-(a.value/b.value)
from v$sysstat a,v$sysstat b
where a.name='parse time cpu' and
b.name='CPU used by this session';

4.7 Parse time CPU to parse time elapsed：通常，该项显示锁竞争比率。

把解析任务交给cpu后，1，cpu花时间去解析；2，cpu等待（由于锁的原因）

公式：parse time cpu / parse time elapsed
执行：
select a.value/b.value
from v$sysstat a,v$sysstat b
where a.name='parse time cpu' and b.name='parse time elapsed';

五，从V$SYSSTAT获取负载间档(Load Profile)数据

5.0 概述

　　负载间档是监控系统吞吐量和负载变化的重要部分，该部分提供如下每秒和每个事务的统计信息：logons cumulative, parse count (total), parse count (hard), executes, physical reads, physical writes, block changes, and redo size.

被格式化的数据可检查'rates'是否过高，或用于对比其它基线数据设置为识别system profile在期间如何变化。例如，5.1 计算每个事务中block changes可用如下公式：

db block changes / ( user commits + user rollbacks )
执行：
select a.value/(b.value+c.value)
from v$sysstat a,v$sysstat b,v$sysstat c
where a.name='db block changes' and
b.name='user commits' and c.name='user rollbacks';

5.2 Blocks changed for each read：这项显示出block changes在block reads中的比例。

它将指出是否系统主要用于只读访问或是主要进行诸多数据操作(如：inserts/updates/deletes)
公式：db block changes / session logical reads
执行：
select a.value/b.value
from v$sysstat a,v$sysstat b
where a.name='db block changes' and
b.name='session logical reads' ;

5.3 Rows for each sort：

公式：sorts (rows) / ( sorts (memory) + sorts (disk) )
执行：
select a.value/(b.value+c.value)
from v$sysstat a,v$sysstat b,v$sysstat c
where a.name='sorts (rows)' and
b.name='sorts (memory)' and c.name='sorts (disk)';

注：以下指标取自Oracle的性能分析工具Statspack所提供的性能分析指标。

1．关于实例效率（Instance Efficiency Percentages）的性能指标

缓冲区未等待率(Buffer Nowait %)       

• 指在缓冲区中获取Buffer的未等待比率。
• 该指标的值应接近100%，如果该值较低，则可能要增大buffer cache。

Redo缓冲区未等待率(Redo NoWait %)       

• 指在Redo缓冲区获取Buffer的未等待比率。       
• 该指标的值应接近100%，如果该值较低，则有2种可能的情况：
  1）online redo log没有足够的空间；
  2）log切换速度较慢。       

缓冲区命中率(Buffer Hit %)       

• 指数据块在数据缓冲区中的命中率。       
• 该指标的值通常应在90%以上，否则，需要调整。如果持续小于90%，可能要加大db_cache_size。但有时，缓存命中率低并不意味着cache设置小了，可能是潜在的全表扫描降低了缓存命中率。       

内存排序率(In-memory Sort %)       

• 指排序操作在内存中进行的比率。当查询需要排序的时候，数据库会话首先选择在内存中进行排序，当内存大小不足的时候，将使用临时表空间进行磁盘排序，但磁盘排序效率和内存排序效率相差好几个数量级。       
• 该指标的值应接近100%，如果指标的值较低，则表示出现了大量排序时的磁盘I/O操作，可考虑加大sort_area_size参数的值。        

共享区命中率(Library Hit %)       

• 该指标主要代表sql在共享区的命中率。       
• 该指标的值通常应在95%以上，否则需要考虑加大共享池（修改shared_pool_size参数值），绑定变量，修改cursor_sharing等参数。       

软解析的百分比(Soft Parse %)       

• 该指标是指Oracle对sql的解析过程中，软解析所占的百分比。软解析（soft parse）是指当Oracle接到Client提交的Sql后会首先在共享池（Shared Pool）里面去查找是否有之前已经解析好的与刚接到的这一个Sql完全相同的Sql。当发现有相同的Sql就直接用之前解析好的结果，这就节约了解析时间以及解析时候消耗的CPU资源。       
• 该指标的值通常应在95%以上，如果低于80%，那么就可能sql基本没被重用，sql没有绑定变量，需要考虑绑定变量。       

闩命中率(Latch Hit %)       

• 指获得Latch的次数与请求Latch的次数的比率。
• 该指标的值应接近100%，如果低于99%，可以考虑采取一定的方法来降低对Latch的争用。       

SQL语句执行与解析的比率(Execute to Parse %)       

• 指SQL语句执行与解析的比率。SQL语句一次解析后执行的次数越多，该比率越高，说明SQL语句的重用性很好。
• 该指标的值应尽可能到高，如果过低，可以考虑设置session_cached_cursors参数。       

共享池内存使用率(Memory Usage %)       

• 该指标是指在采集点时刻，共享池（share pool）内存被使用的比例。       
• 这指标的值应保持在75%~90%,如果这个值太低，就浪费内存，如果太高，会使共享池外部的组件老化，如果SQL语句被再次执行，则就会发生硬分析。       

2．关于等待事件（Wait events）的性能指标

文件分散读取(db file scattered read (cs))       

• 该等待事件通常与全表扫描有关。因为全表扫描是被放入内存中进行的进行的，通常情况下它不可能被放入连续的缓冲区中，所以就散布在缓冲区的缓存中。       
• 如果这个等待事件比较显著，可能说明对于某些全表扫描的表，没有创建索引或没有创建合适的索引。尽管在特定条件下执行全表扫描可能比索引扫描更有效，但如果出现这种等待时，最好检查一下这些全表扫描是否必要。       

文件顺序读取(db file sequential read (cs))       

• 该等待事件通常与单个数据块相关的读取操作有关。       
• 如果这个等待事件比较显著，可能表示在多表连接中，表的连接顺序存在问题，或者可能不合适地使用了索引。对于大量事务处理、调整良好的系统，这一数值大多是很正常的，但在某些情况下，它可能暗示着系统中存在问题。应检查索引扫描，以保证每个扫描都是必要的，并检查多表连接的连接顺序。另外DB_CACHE_SIZE 也是这些等待出现频率的决定因素。

缓冲区忙(buffer busy (cs))       

• 当一个会话想要访问缓存中的某个块，而这个块正在被其它会话使用时，将会产生该等待事件。这时候，其它会话可能正在从数据文件向缓存中的这个块写入信息，或正在对这个块进行修改。       
• 出现这个等待事件的频度不应大于1%。如果这个等待事件比较显著，则需要根据等待事件发生在缓存中的哪一块（如字段头部、回退段头部块、回退段非头部块、数据块、索引块等），采取相应的优化方法。

(enqueue (cs))       

• enqueue 是一种保护共享资源的锁定机制。该锁定机制保护共享资源，如记录中的数据，以避免两个人在同一时间更新同一数据。enqueue 包括一个排队机制，即FIFO(先进先出)排队机制。注意：Oracle 的latch 机制不是FIFO。Enqueue 等待通常指的是ST enqueue、HW enqueue、TX4 enqueue 和TM enqueue。       
• 如果enqueue等待事件比较显著，则需要根据enqueue等待类型，采取相应的优化方法。

闩释放(latch free (cs))       

• 该等待事件意味着进程正在等待其他进程已持有的latch。
• latch是一种低级排队机制(它们被准确地称为相互排斥机制),用于保护系统全局区域(SGA)中共享内存结构。latch 就像是一种快速地被获取和释放的内存锁。latch 用于防止共享内存结构被多个用户同时访问。       
• 对于常见的Latch等待通常的解决方法：
  1）Share pool latch：在OLTP应用中应该更多的使用绑定变量以减少该latch的等待。
  2）Library cache latch：同样的需要通过优化sql语句使用绑定变量减少该latch的等待。       

日志文件同步(log file sync (cs))       

• 这个等待事件是指当一个会话完成一个事务（提交或者回滚数据）时，必须等待LGWR进程将会话的redo信息从日志缓冲区写到日志文件后，才能继续执行下去。       
• 这个等待事件的时间过长，可能是因为commit太频繁或者lgwr进程一次写日志的时间太长（可能是因为一次log io size太大），可调整 _log_io_size，结合log_buffer,使得 (_log_io_size*db_block_size)*n = log_buffer，这样可避免和增大log_buffer引起冲突，或者可以将日志文件存放在高速磁盘上。

命令：top

命令执行后显示：

top - 16:34:45 up 20 days, 22:49, 10 users,  load average: 0.16, 0.15, 0.10
Tasks: 372 total,   1 running, 371 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.6%us,  1.0%sy,  0.0%ni, 98.3%id,  0.2%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   3745792k total,  3719544k used,    26248k free,    11992k buffers
Swap:  4192924k total,  2073508k used,  2119416k free,   935288k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                      

    1 root      15   0  2088  548  524 S  0.0  0.0   1:10.83 init              
    2 root      RT  -5     0    0    0 S  0.0  0.0   0:01.40 migration/0       
    3 root      34  19     0    0    0 S  0.0  0.0   0:00.09 ksoftirqd/0       
    4 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 watchdog/0        
    5 root      RT  -5     0    0    0 S  0.0  0.0   0:01.10 migration/1       
    6 root      34  19     0    0    0 S  0.0  0.0   0:00.13 ksoftirqd/1       
    7 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 watchdog/1        
    8 root      RT  -5     0    0    0 S  0.0  0.0   0:01.03 migration/2       
    9 root      34  19     0    0    0 S  0.0  0.0   0:00.07 ksoftirqd/2       

统计信息内容解释：

第一行是任务队列信息，同 uptime 命令的执行结果。

第二行为进程信息。
　　total 进程总数
　　running 正在运行的进程数
　　sleeping 睡眠的进程数
　　stopped 停止的进程数
　　zombie 僵尸进程数

第三行为CPU信息。
    us 用户空间占用CPU百分比
　　sy 内核空间占用CPU百分比
　　ni 用户进程空间内改变过优先级的进程占用CPU百分比
　　id 空闲CPU百分比
　　wa 等待输入输出的CPU时间百分比
　　hi 硬件中断
　　si 软件中断

最后两行为内存信息。

Mem:total 物理内存总量
　　used 使用的物理内存总量
　　free 空闲内存总量
　　buffers 用作内核缓存的内存量

Swap:total 交换区总量
　　used 使用的交换区总量
　　free 空闲交换区总量
　　cached 缓冲的交换区总量

进程信息区

    默认情况下仅显示比较重要的 PID、USER、PR、NI、VIRT、RES、SHR、S、%CPU、%MEM、TIME+、COMMAND 列。

PID  进程id
USER 进程所有者的用户名
PR   优先级
NI   nice值。负值表示高优先级，正值表示低优先级
VIRT 进程使用的虚拟内存总量，单位kb。VIRT=SWAP+RES
RES  进程使用的、未被换出的物理内存大小，单位kb。RES=CODE+DATA
SHR  共享内存大小，单位kb
S 进程状态：
  　 D=不可中断的睡眠状态
　　 R=运行
　　 S=睡眠
　　 T=跟踪/停止
　　 Z=僵尸进程
%CPU    上次更新到现在的CPU时间占用百分比
%MEM    进程使用的物理内存百分比
TIME+   进程使用的CPU时间总计，单位1/100秒
COMMAND 命令名/命令行

top：交互式工具，用于监视性能，包含整个Linux系统的性能概要和进程信息。

vmstat：报告内存和交换区的使用信息，也可以报告部分CPU和I/O信息。

free：主要是报告内存和交换区信息。

RPM:Red Hat Package Manager，Red Hat 软件包管理，包含procs rpm和sysstat rpm两种。proc rpm包含top、vmstat和free。sysstat rmp包含iostat和sar。

转载自：http://www.bitscn.com/os/linux/200802/128193.html

vmstat是Virtual Meomory Statistics（虚拟内存统计）的缩写, 是实时系统监控工具。该命令通过使用knlist子程序和/dev/kmen伪设备驱动器访问这些数据，输出信息直接打印在屏幕。vmstat反馈的与CPU相关的信息包括：

    1.多少任务在运行

    2.CPU使用的情况

    3.CPU收到多少中断

    4.发生多少上下文切换

vmstat的语法如下： vmstat [delay [count]]

参数 解释

delay 相邻的两次采样的间隔时间

count 采样的次数，count只能和delay一起使用

当没有参数时，vmstat则显示系统启动以后所有信息的平均值。有delay时，第一行的信息自系统启动以来的平均信息。从第二行开始，输出为前一个delay时间段的平均信息。当系统有多个CPU时，输出为所有CPU的平均值。

参数 解释

任务的信息(procs)

   r 在internal时间段里，运行队列里等待CPU的任务的个数，即不包含vmstat进程 procs_running-1

   b 在internal时间段里，被资源阻塞的任务数（I/0，页面调度，等等.），通常情况下是接近0的procs_blocked

CPU信息(cpu)

    us 在internal时间段里，用户态的CPU时间(%)，包含 nice值为负进程 (?user+?nice)/?total*100

    sy 在internal时间段里，核心态的CPU时间(%) (?system+?irq+?softirq)/?total*100

    id 在internal时间段里，cpu空闲的时间，不包括等待i/o的时间(%) ?idle/?total*100

    wa 在internal时间段里，等待i/o的时间(%) ?iowait/?total*100

系统信息(system)

    in 在internal时间段里，每秒发生中断的次数 ?intr/interval

    cs 在internal时间段里，每秒上下文切换的次数，即每秒内核任务交换的次数 ?ctxt/interval

范例1：average mode (粗略信息)

当vmstat不带参数时，对应的输出值是从系统启动以来的平均值，而r和b则对应的是完成这一命令时，系统的值。从下面例子，可以看出系统基本出去闲置状态（idle）。自启动以来，CPU在用户态消耗时间为5%，在核心态消耗为本1%，剩下的为闲置时间。需要指出的是：这里的用户态时间包括nice值为负的进程的时间。

CODE:

[root@localhost ~]# vmstat
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
1 0 0 4580 428 98516 0 0 49 6 15 19 2 1 96 1
[root@localhost ~]#

范例2：average mode (详细信息)

命令格式： vmstat –s

这里只讨论与CPU相关信息。“CPU ticks”表示自系统启动CPU运行时间，这里以tick为时间单位。用tick来西安市us,sy id 和wa的时间；forks指自从系统启动以来，所创建的新任务的个数。这些信息从/proc/stat 的第一行和”processes”行获得。

CODE:

[root@localhost ~]# vmstat -s
255280 total memory
244216 used memory
206624 active memory
21208 inactive memory
11064 free memory
628 buffer memory
91396 swap cache
255992 total swap
24 used swap
255968 free swap
973400 non-nice user cpu ticks
477 nice user cpu ticks
206168 system cpu ticks
43567714 idle cpu ticks
373234 IO-wait cpu ticks
62732 IRQ cpu ticks
1972 softirq cpu ticks
22366502 pages paged in
88756936 pages paged out
0 pages swapped in
0 pages swapped out
135634319 interrupts
137288441 CPU context switches
1134440368 boot time
208990 forks
[root@localhost ~]#
 

结果解释

non-nice user cpu ticks 自系统启动以来，CPU在用户态下运行非nice进程的时间，单位为jiffies user

nice user cpu ticks 自系统启动以来，CPU在用户态下运行nice进程的时间，单位为jiffies nice

system cpu ticks 自系统启动以来，CPU处于系统状态的时间，单位为jiffies sys

idle cpu ticks 自系统启动以来，CPU处于闲置状态的时间，单位为jiffies idle

IO-wait cpu ticks 自系统启动以来，CPU处理IO中断的时间，单位为jiffies iowait

IRQ cpu ticks 自系统启动以来，CPU处理硬中断的时间，单位为jiffies irq

softing cpu ticks 自系统启动以来，CPU处理软中断的时间，单位为jiffies Softirq

interrupts 自系统启动以来，发生的所有的中断的次数目 Intr

CPU context switches 自系统启动以来，发生的上下文交换的次数 Ctxt

boot time 自系统启动以来到现在运行的时间，单位为秒。 btime

forks 自系统启动以来所创建的任务的个数目。 Process

范例3：定期采样(delay [count])

定期采样数据是指每隔delay时间，采样一次。当count 为0时，vmstat 将不停地定期报告信息；否则当报告count次后，vmstat 命令停止运行。

第一行的信息如同范例1，是自系统启动以来的平均信息。从第二行开始，每行的意思是：r和b采样那一时刻系统运行队列和等待队列的情况；而usystem参数（in,cs）以及CPU参数（us,sy,id,wa）对应的输出值是系统在前一个delay的情况。

从下面例子可以看出上下文交换的次数小于中断的发生次数。当系统大部分时间是空闲并且中断大部分是时间中断时，这种现象极可能发生。当时间中断发生时, 因为调度器没有什么任务可调度，所以很少发生上下文切换。

CODE:

[root@localhost ~]# vmstat 2 4
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
1 0 24 11032 652 91396 0 0 49 6 15 19 2 1 96 1
0 0 24 11032 652 91396 0 0 0 0 377 464 1 0 99 0
0 0 24 11024 652 91396 0 0 0 0 387 476 1 0 100 0
0 0 24 11024 652 91396 0 0 0 0 323 377 0 0 100 0
[root@localhost ~]#

转载自：http://www.bitscn.com/os/linux/200802/128193.html

uptime是Linux系统常用的命令，用来报告系统已经运行多长时间，依此显示的信息：现在时间，系统已经运行了的时间，目前有多少登陆用户， 1分钟系统平均负载，5分钟系统平均负载，15分钟系统平均负载。该命令从/proc/loadavg 中获得load average的信息。

范例1：系统只用一个CPU

[root@localhost ~]# uptime

12:20:49 up 3 days,9:20, 5 users, load average 1.10 1.32 1.15

对于一个CPU的系统来说，范例1中的平均负载高了些。通常来说：如果系统有n个CPU而且平均负载小于n,则说明某些CPU还有空闲的时间片。通过该命令，你能知道CPU是否繁忙，但是无法知道为什么忙。

转载自：http://www.bitscn.com/os/linux/200802/128193.html

/proc/loadavg

该文件中的所有值都是从系统启动开始累计到当前时刻。该文件只给出了所有CPU的集合信息，不能该出每个CPU的信息。

[root@localhost ~]# cat /proc/loadavg

4.61 4.36 4.15 9/84 5662

每个值的含义为：

参数 解释

lavg_1 (4.61) 1-分钟平均负载

lavg_5 (4.36) 5-分钟平均负载

lavg_15(4.15) 15-分钟平均负载

nr_running (9) 在采样时刻，运行队列的任务的数目，与/proc/stat的procs_running表示相同意思

nr_threads (84) 在采样时刻，系统中活跃的任务的个数（不包括运行已经结束的任务）

last_pid(5662) 最大的pid值，包括轻量级进程，即线程。

假设当前有两个CPU，则每个CPU的当前任务数为4.61/2=2.31

[work@tester ~]$ cat /proc/stat

cpu  4648777 242817 2539007 699596054 8396284 0 42795 89960
cpu0 1411403 145057 861446 169629599 6803337 0 14491 23587
cpu1 1164400 29715 661794 176372871 628842 0 9782 21518
cpu2 1042000 39424 516241 176764077 495361 0 9320 22497
cpu3 1030972 28621 499524 176829506 468742 0 9200 22356
intr 1620630787 0 2 0 0 0 0 0 0 1 0 0 0 4 0 0 0 0 0 106 0 19557449 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 4 639817 734310 860777 188320 64664118 0 15555559 0 0 0 0 0 0 0 0 0 0 0 0 361839192 19478113 44 19020227 179 350986900 18785624 177 365970867 18587107 161 363761636 93 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
ctxt 5732137946
btime 1293011125
processes 2373776
procs_running 1
procs_blocked 0

输出解释

CPU 以及CPU0、CPU1、CPU2、CPU3每行的每个参数意思为：

参数 解释

user：从系统启动开始累计到当前时刻，用户态的CPU时间，不包含 nice值为负进程。1jiffies=0.01秒（单位：jiffies）

nice：从系统启动开始累计到当前时刻，nice值为负的进程所占用的CPU时间（单位：jiffies）

system：从系统启动开始累计到当前时刻，核心时间（单位：jiffies）

idle：从系统启动开始累计到当前时刻，除硬盘IO等待时间以外其它等待时间（单位：jiffies）

iowait：从系统启动开始累计到当前时刻，硬盘IO等待时间（单位：jiffies）

irq：从系统启动开始累计到当前时刻，硬中断时间（单位：jiffies）

softirq：从系统启动开始累计到当前时刻，软中断时间（单位：jiffies）

CPU时间=user+system+nice+idle+iowait+irq+softirq

“intr”这行给出中断的信息，第一个为自系统启动以来，发生的所有的中断的次数；然后每个数对应一个特定的中断自系统启动以来所发生的次数。

“ctxt”给出了自系统启动以来CPU发生的上下文交换的次数。

“btime”给出了从系统启动到现在为止的时间，单位为秒。

“processes”：自系统启动以来所创建的任务的个数目。

“procs_running”：当前运行队列的任务的数目。

“procs_blocked”：当前被阻塞的任务的数目。

转载自：http://bbs.51testing.com/thread-113013-1-1.html

基本思路：利用Tomcat自带的Status页面

基本实现步骤：

1.打开Tomcat的status页面，方法为编辑Tomcat的conf目录下的tomcat-users.xml文件，在文件中添加
<tomcat-users>
  <role rolename="manager"/>
  <user username="admin" password="pass" roles="manager"/>
</tomcat-users>
这里的password和username请自行修改，保存之后重启tomcat，打开http://localhost:8080/manager/status就可以看到status页面了

2.通常我们需要读取的是另一个页面，即http://localhost:8080/manager/status?XML=true，这样整个服务器的性能数据就以一个单行的xml文件形式表示了。

3.读取这个页面的信息，然后对其进行xml或者字符串分析和处理，以取得我们需要的性能数据。

4.上面得到的只是当前情况下的性能数据，要获得一个阶段的性能数据，必须设定采样频率，定时读取，将数据汇总并分析

5.对得到数据进行生成图表等操作。