DB buffer bussy wait 分析一例
####sample 1:
DB层分析OI
DB层分析OI的信息如下：
1. 异常时间段, Logical reads:/ Physical reads/ Physical write 指标都低于正常时间段。说明数据库本身消耗i/o 并不高。但是nmon显示disk 读写非常高，
同时现场分析， I/O 资源消耗最大可达40M-70M/s,任务可以顺利完成。同时注意到
通过topas 来看，在一些时候，hdisk 在 tps和kbps 为0的情况下，磁盘繁忙程度达到99%，所以建议如下：
是这个现在已有的信息能够看到的一些问题，还需要OS层面给一些东西，需要OS介入帮助看看底层是否有什么问题。请主机组检查存储
2. 等待事件buffer busy waits 占首位，消耗了很多资源，主要是sql 2mwvn9xwq1tz3 消耗。建议检查sql
检查这个sql 执行计划2mwvn9xwq1tz3。
|
Elapsed Time (s) |
Executions |
Elapsed Time per Exec (s) |
%Total |
%CPU |
%IO |
SQL Id |
SQL Module |
SQL Text |
|
80,962.92 |
24,804 |
3.26 |
33.97 |
0.00 |
0.00 |
e:IEU:cp:IEU_WL_CS |
select (RUNNING_PROCESSES-MAX_... |
分析sql 结果：
Sql 执行计划没有变化。主要消耗在buffer busy wait ,说明当时缓存区争用，怀疑跟系统I/O 处理不过来，导致缓存存在问题。
SQL_ID 2mwvn9xwq1tz3
--------------------
select (RUNNING_PROCESSES-MAX_PROCESSES) ,MAX_PROCESSES
,NVL(SLEEP_SECONDS,0) ,DIAGNOSTIC_LEVEL into :b0,:b1,:b2,:b3:b4 from
FND_CONCURRENT_QUEUES where ((DBLICATION_ID=:b5 and
CONCURRENT_QUEUE_ID=:b6) and (TARGET_NODE=:b7 or (TARGET_NODE is null
and :b7 is null )))
Plan hash value: 356935968
--------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 1 (100)| |
| 1 | TABLE ACCESS BY INDEX ROWID| FND_CONCURRENT_QUEUES | 1 | 22 | 1 (0)| 00:00:01 |
| 2 | INDEX UNIQUE SCAN | FND_CONCURRENT_QUEUES_U1 | 1 | | 0 (0)| |
--------------------------------------------------------------------------------------------------------
详细分析如下:
-》 1 。正常时间段：等待事件正常， Logical reads:/ Physical reads/ Physical write 指标都高于 异常时间段。
|
|
Snap Time |
Sessions |
Cursors/Session |
|
|
Begin |
36769 |
12-6月 -17 20:00:52 |
216 |
10.5 |
|
End |
36773 |
13-6月 -17 00:00:22 |
229 |
9.3 |
|
Elapsed: |
239.51 (mins) |
|||
|
DB |
1,570.72 (mins) |
Top 5 Timed Foreground Events
|
Event |
Waits |
Time(s) |
Avg wait (ms) |
% DB time |
Wait Class |
|
db file sequential read |
5,750,530 |
23,950 |
4 |
25.41 |
User I/O |
|
log |
72,789 |
15,988 |
220 |
16.96 |
Configuration |
|
DB |
10,941 |
11.61 |
|||
|
SQL*Net |
61,789 |
7,296 |
118 |
7.74 |
Network |
|
direct |
385,065 |
6,336 |
16 |
6.72 |
User |
Segments by Buffer Busy Waits
% of Capture shows % of Buffer Busy Waits for each top segment
compared
with total Buffer Busy Waits for all segments captured by the
Snapshot
|
Owner |
Tablespace Name |
Object Name |
Subobject Name |
Obj. Type |
Buffer Busy Waits |
% of Capture |
|
MSC |
DBS_TS_INTERFACE |
MSC_ST_SYSTEM_ITEMS |
SYSTEM_ITEMS_3021 |
TABLE |
13,842 |
45.12 |
|
DATALOAD |
TS_DATA_LOAD |
ZTE_ERP_WIP_DETAIL |
TABLE |
6,058 |
19.75 |
|
|
DBLSYS |
DBS_TS_TX_DATA |
FND_CONCURRENT_QUEUES |
TABLE |
5,119 |
16.69 |
Load Profile
|
Per Second |
Per Transaction |
Per Exec |
Per Call |
|
|
DB |
6.6 |
0.5 |
0.00 |
0.11 |
|
DB |
0.8 |
0.1 |
0.00 |
0.01 |
|
Redo |
6,145,675.1 |
497,949.9 |
||
|
Logical reads: |
223,510.5 |
18,109.8 |
||
|
Block |
20,265.5 |
1,642.0 |
||
|
Physical reads: |
2,507.0 |
203.1 |
||
|
Physical writes: |
3,069.3 |
248.7 |
||
|
User |
60.5 |
4.9 |
||
|
Parses: |
3.3 |
0.3 |
||
|
Hard |
0.9 |
0.1 |
||
|
W/A |
3.7 |
0.3 |
||
|
Logons: |
0.2 |
0.0 |
||
|
Executes: |
2,988.9 |
242.2 |
||
|
Rollbacks: |
0.3 |
0.0 |
||
|
Transactions: |
12.3 |
-》 2 .异常时间段。等待事件buffer busy waits 占首位，消耗了很多资源，主要是sql 2mwvn9xwq1tz3 消耗。
Logical reads:/ Physical
reads/ Physical write 指标都低于正常时间段。说明数据库本身消耗i/o 并不高。，
|
|
Snap Time |
Sessions |
Cursors/Session |
|
|
Begin |
36817 |
14-Jun-17 20:00:02 |
228 |
12.8 |
|
End |
36821 |
15-Jun-17 00:00:21 |
235 |
10.9 |
|
Elapsed: |
240.31 (mins) |
|||
|
DB |
6,207.36 (mins) |
|
Buffer |
29,184M |
29,184M |
Std |
8K |
|
Shared |
10,240M |
10,240M |
Log |
72,708K |
|
Event |
Waits |
Time(s) |
Avg wait (ms) |
% DB time |
Wait Class |
|
buffer busy waits |
78,775 |
207,914 |
2639 |
55.82 |
Concurrency |
Segments
by Buffer Busy Waits
- % of Capture shows % of
Buffer Busy Waits for each top segment compared - with total Buffer Busy Waits
for all segments captured by the Snapshot
|
Owner |
Tablespace Name |
Object Name |
Subobject Name |
Obj. Type |
Buffer Busy Waits |
% of Capture |
|
DBLSYS |
DBS_TS_TX_DATA |
FND_CONCURRENT_QUEUES |
TABLE |
90,802 |
72.49 |
|
2mwvn9xwq1tz3 |
select |
Load
Profile
|
Per Second |
Per Transaction |
Per Exec |
Per Call |
|
|
DB |
20.0 |
1.7 |
0.06 |
0.15 |
|
DB |
0.2 |
0.0 |
0.00 |
0.00 |
|
Redo |
1,836,990.9 |
154,577.6 |
||
|
Logical reads: |
35,973.5 |
3,027.1 |
||
|
Block |
5,531.3 |
465.4 |
||
|
Physical reads: |
343.4 |
28.9 |
||
|
Physical writes: |
550.6 |
46.3 |
||
|
User |
132.6 |
11.2 |
||
|
Parses: |
3.0 |
0.3 |
||
|
Hard |
0.8 |
0.1 |
||
|
W/A |
2.6 |
0.2 |
||
|
Logons: |
0.1 |
0.0 |
||
|
Executes: |
332.7 |
28.0 |
||
|
Rollbacks: |
0.5 |
0.0 |
||
|
Transactions: |
11.9 |
è 3. 检查这个sql 执行计划2mwvn9xwq1tz3。
6.11没问题：
6.14有问题：
PS:
事件参数说明：
事件名：buffer busy waits
参数一：file#
参数二：block#
参数三：9i -原因码，10g - block class#
事件说明：
一、ORACLE会话正在等待PIN住一个缓冲区，会话必须在读取或修改缓冲区之前将该缓冲区PIN住。
二、在任何时侯只有一个进程可以PIN住一个缓冲区。
三、buffer busy waits表明读/读、读/写、写/写争用。
四、根据P3中指明的原因码有不同的处理方式。
五、现象描述：
六、该事件只与SGA中缓冲区相关，与会话私有的PGA中执行的读/写操作无关。
七、处理该等待事件时主要注意以下四方面：
from dba_extents s
where <P2的值> between s.block_id and (s.block_id + s.blocks -1) and s.file_id = <P1的值>
八、虽然buffer busy waits事件的发生可能至少有十个不同的原因，但是代码130和220是最常见的原因。基本上，小于200的代码号意味着这种等待是和I/O有关的。
带有原因码130的数据块(类#1)争用
2) 当多个会话请求不在缓冲存储器中的相同数据块时，ORACLE可以聪明地防止每个会话进行相同的操作系统I/O调用。否则，这可能严重地增加系统I/O的数量，所以，ORACLE只允许一个会话执行实际的I/O，而其他的会话在buffer busy waits上等待块，执行I/O的会话在db file sequential read或db file scattered read等待事件上等待。
3) 可在v$session视图中检查SESSION的注册时间，并且等待事件db file sequential(scattered) read和buffer busy waits等待相同的文件号和块号。
4) 解决方法：优化SQL语句，尽可能地减少逻辑读和物理读；
带有原因码220的数据块(类#1)争用
2) 如果数据块的尺寸较大(>=16K)，则可能强化这种现象，因为较大的块一般在每个块中包含更多的行。
3) 减少这种情况的等待的方法：减少并发；减少块中行的数量；在另一个具有较小块尺寸的表空间中重新构建对象。
4) 具体方法说明：
使用较大的PCTFREE重新构建表或索引；
使用alter table <table_name> minimize records_pre_block命令改变表以最小化每个块的最小行数
从ORACLE9i开始，可以在另一个具有较小块尺寸的表空间中移动或重新构建对象。
注：虽然这些方法可以最小化buffer busy waits问题，但它们无疑会增加全表扫描时间和磁盘空间利用率。
数据段头(类#4)的争用
注：进程出于两个主要原因访问段头，一是，获得或修改FREELISTS信息；二是，为了扩展高水位标记(HWM)。
2) 减少这种情况的等待的方法：
>> 对使用自由表进行段管理的表，增加确认对象的FREELISTS和FREELIST GROUPS(注：FREELIST GROUPS的增加也是必须的)；
>> 确保FCTFREE和PCTUSED之间的间隙不是太小，从而可以最小化FREELIST的块循环。
>> 下一区的尺寸不能太小，当区高速扩张时，建立的新区需要修改在段头中区映射表。可以考虑将对象移动到合理的、统一尺寸的本地管理的表空间中。
撤销段头(类#17)的争用
2) 可以创建并启用私有回滚段，以减少每个回滚段的事务数量。需要修改init.ora文件中的ROLLBACK_SEGMENTS参数。
3) 如果使用公用回滚段可以减少初始化参数transactions_per_rollback_segment的值，ORACLE通过transactions/transactions_per_rollback_segment来获取公有回滚段的最小数量。
撤销块的争用(类#18)
2) 这是应用程序存在问题，当应用程序在不同时间内运行查询和DML时，这种问题不会存在。
附注：
一、查看系统所有段的有关buffer busy waits事件的统计：
SELECT *
FROM v$segment_statistics s
WHERE s.statistic_name = 'buffer busy waits'
AND s.owner <> 'SYS'
######sampe 2:
free buffer waits
1. 10046 debug show one sqll normal run 1S, issue time run 10s.
0:42:35 SQL> oradebug setmypid
Statement processed.
10:44:02 SQL> oradebug event 10046 trace name context forever,level 12;
Statement processed.
10:44:19 SQL> /
TABLESPACE_NAME maxbyes_GB
------------------------------------------------------------ ----------
bytes_GB free_GB use_GB use_% maxuse_%
---------- ---------- ---------- ---------- ----------
USERS 31.9999847
.48828125 .450134277 .038146973 7.81 .12
12 rows selected.
10:44:34 SQL> oradebug event 10046 trace name context off
10:45:08 SQL> oradebug tracefile_name
2.sql show 10s consume in fetch time, and more check show wait evnet " free buffer waits " consume 10s. it it the cause.
SELECT a.tablespace_name ,b.maxbytes/1024/1024/1024 "maxbyes_GB",total/1024/1024/1024 "bytes_GB",free/1024/1024/1024 "free_GB",(total-free) /1024/1024/1024 "use_GB",
ROUND((total-free)/total,4)*100 "use_%",ROUND((total-free)/b.maxbytes,4)*100 "maxuse_%"
FROM
(SELECT tablespace_name,SUM(bytes) free FROM DBA_FREE_SPACE
GROUP BY tablespace_name
) a,
(SELECT tablespace_name,sum(case autoextensible when 'YES' then maxbytes else bytes end) maxbytes,SUM(bytes) total FROM DBA_DATA_FILES
GROUP BY tablespace_name
) b
WHERE a.tablespace_name=b.tablespace_name
order by "maxuse_%" desc
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.01 0.11 1 4 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 0.46 10.86 7051 10244 360 12 < fetch is use 10 s, but cpu only have 0.3s, IO is small 7052 , the more is in wait evnet.
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 4 0.48 10.98 7052 10248 360 12
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS
Number of plan statistics captured: 1
Rows (1st) Rows (avg) Rows (max) Row Source Operation
---------- ---------- ---------- ---------------------------------------------------
12 12 12 SORT ORDER BY (cr=20469 pr=7052 pw=0 time=11032670 us cost=69 size=122 card=2)
12 12 12 HASH JOIN (cr=20469 pr=7052 pw=0 time=11032536 us cost=68 size=122 card=2)
12 12 12 VIEW (cr=156 pr=0 pw=0 time=11691 us cost=5 size=74 card=2)
12 12 12 HASH GROUP BY (cr=156 pr=0 pw=0 time=11678 us cost=5 size=80 card=2)
36 36 36 VIEW DBA_DATA_FILES (cr=156 pr=0 pw=0 time=13109 us cost=4 size=80 card=2)
36 36 36 UNION-ALL (cr=156 pr=0 pw=0 time=13108 us)
0 0 0 NESTED LOOPS (cr=40 pr=0 pw=0 time=2305 us cost=2 size=369 card=1)
0 0 0 NESTED LOOPS (cr=40 pr=0 pw=0 time=2304 us cost=1 size=351 card=1)
0 0 0 NESTED LOOPS (cr=40 pr=0 pw=0 time=2302 us cost=1 size=338 card=1)
36 36 36 FIXED TABLE FULL X$KCCFN (cr=0 pr=0 pw=0 time=575 us cost=0 size=310 card=1)
0 0 0 TABLE ACCESS BY INDEX ROWID FILE$ (cr=40 pr=0 pw=0 time=210 us cost=1 size=28 card=1)
36 36 36 INDEX UNIQUE SCAN I_FILE1 (cr=4 pr=0 pw=0 time=85 us cost=0 size=0 card=1)(object id 43)
0 0 0 FIXED TABLE FIXED INDEX X$KCCFE (ind:1) (cr=0 pr=0 pw=0 time=0 us cost=0 size=39 card=3)
0 0 0 TABLE ACCESS CLUSTER TS$ (cr=0 pr=0 pw=0 time=0 us cost=1 size=18 card=1)
0 0 0 INDEX UNIQUE SCAN I_TS# (cr=0 pr=0 pw=0 time=0 us cost=0 size=0 card=1)(object id 7)
36 36 36 NESTED LOOPS (cr=116 pr=0 pw=0 time=10680 us cost=2 size=429 card=1)
36 36 36 NESTED LOOPS (cr=76 pr=0 pw=0 time=9250 us cost=1 size=411 card=1)
36 36 36 NESTED LOOPS (cr=76 pr=0 pw=0 time=1950 us cost=1 size=398 card=1)
36 36 36 NESTED LOOPS (cr=36 pr=0 pw=0 time=1306 us cost=0 size=388 card=1)
36 36 36 FIXED TABLE FULL X$KCCFN (cr=0 pr=0 pw=0 time=366 us cost=0 size=310 card=1)
36 36 36 FIXED TABLE FIXED INDEX X$KTFBHC (ind:1) (cr=36 pr=0 pw=0 time=609 us cost=0 size=78 card=1)
36 36 36 TABLE ACCESS BY INDEX ROWID FILE$ (cr=40 pr=0 pw=0 time=326 us cost=1 size=10 card=1)
36 36 36 INDEX UNIQUE SCAN I_FILE1 (cr=4 pr=0 pw=0 time=121 us cost=0 size=0 card=1)(object id 43)
36 36 36 FIXED TABLE FIXED INDEX X$KCCFE (ind:1) (cr=0 pr=0 pw=0 time=5605 us cost=0 size=39 card=3)
36 36 36 TABLE ACCESS CLUSTER TS$ (cr=40 pr=0 pw=0 time=516 us cost=1 size=18 card=1)
36 36 36 INDEX UNIQUE SCAN I_TS# (cr=4 pr=0 pw=0 time=189 us cost=0 size=0 card=1)(object id 7)
12 12 12 VIEW (cr=20313 pr=7052 pw=0 time=11019748 us cost=62 size=240 card=10)
12 12 12 HASH GROUP BY (cr=20313 pr=7052 pw=0 time=11019746 us cost=62 size=240 card=10)
3034 3034 3034 VIEW DBA_FREE_SPACE (cr=20313 pr=7052 pw=0 time=34905 us cost=61 size=106560 card=4440)
3034 3034 3034 UNION-ALL (cr=20313 pr=7052 pw=0 time=33767 us)
0 0 0 NESTED LOOPS (cr=22 pr=0 pw=0 time=93 us cost=3 size=67 card=1)
0 0 0 NESTED LOOPS (cr=22 pr=0 pw=0 time=91 us cost=3 size=61 card=1)
0 0 0 TABLE ACCESS FULL FET$ (cr=22 pr=0 pw=0 time=90 us cost=3 size=39 card=1)
0 0 0 TABLE ACCESS CLUSTER TS$ (cr=0 pr=0 pw=0 time=0 us cost=0 size=22 card=1)
0 0 0 INDEX UNIQUE SCAN I_TS# (cr=0 pr=0 pw=0 time=0 us cost=0 size=0 card=1)(object id 7)
0 0 0 INDEX UNIQUE SCAN I_FILE2 (cr=0 pr=0 pw=0 time=0 us cost=0 size=6 card=1)(object id 44)
3003 3003 3003 NESTED LOOPS (cr=26 pr=0 pw=0 time=31573 us cost=7 size=3796 card=52)
3003 3003 3003 NESTED LOOPS (cr=22 pr=0 pw=0 time=26185 us cost=7 size=3484 card=52)
12 12 12 TABLE ACCESS FULL TS$ (cr=22 pr=0 pw=0 time=147 us cost=7 size=280 card=10)
3003 3003 3003 FIXED TABLE FIXED INDEX X$KTFBFE (ind:1) (cr=0 pr=0 pw=0 time=50358 us cost=0 size=195 card=5)
3003 3003 3003 INDEX UNIQUE SCAN I_FILE2 (cr=4 pr=0 pw=0 time=2250 us cost=0 size=6 card=1)(object id 44)
31 31 31 NESTED LOOPS (cr=20243 pr=7052 pw=0 time=9059909 us cost=36 size=473688 card=4386)
31 31 31 HASH JOIN (cr=20239 pr=7052 pw=0 time=9059463 us cost=36 size=1678716 card=16458)
312 312 312 HASH JOIN (cr=52 pr=0 pw=0 time=1131 us cost=16 size=14615 card=395)
12 12 12 TABLE ACCESS FULL TS$ (cr=22 pr=0 pw=0 time=96 us cost=7 size=280 card=10)
312 312 312 TABLE ACCESS FULL RECYCLEBIN$ (cr=30 pr=0 pw=0 time=123 us cost=9 size=3582 card=398)
92383 92383 92383 FIXED TABLE FULL X$KTFBUE (cr=20187 pr=7052 pw=0 time=6617310 us cost=19 size=6500000 card=100000)
31 31 31 INDEX UNIQUE SCAN I_FILE2 (cr=4 pr=0 pw=0 time=81 us cost=0 size=6 card=1)(object id 44)
0 0 0 NESTED LOOPS (cr=22 pr=0 pw=0 time=104 us cost=15 size=89 card=1)
0 0 0 NESTED LOOPS (cr=22 pr=0 pw=0 time=100 us cost=15 size=89 card=133)
0 0 0 NESTED LOOPS (cr=22 pr=0 pw=0 time=99 us cost=10 size=80 card=1)
0 0 0 NESTED LOOPS (cr=22 pr=0 pw=0 time=96 us cost=10 size=74 card=1)
0 0 0 TABLE ACCESS FULL TS$ (cr=22 pr=0 pw=0 time=95 us cost=7 size=66 card=3)
0 0 0 TABLE ACCESS CLUSTER UET$ (cr=0 pr=0 pw=0 time=0 us cost=1 size=52 card=1)
0 0 0 INDEX RANGE SCAN I_FILE#_BLOCK# (cr=0 pr=0 pw=0 time=0 us cost=1 size=0 card=1)(object id 9)
0 0 0 INDEX UNIQUE SCAN I_FILE2 (cr=0 pr=0 pw=0 time=0 us cost=0 size=6 card=1)(object id 44)
0 0 0 INDEX RANGE SCAN RECYCLEBIN$_TS (cr=0 pr=0 pw=0 time=0 us cost=1 size=0 card=133)(object id 144)
0 0 0 TABLE ACCESS BY INDEX ROWID RECYCLEBIN$ (cr=0 pr=0 pw=0 time=0 us cost=5 size=9 card=1)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 2 0.00 0.00
control file sequential read 157 0.00 0.00
db file sequential read 7052 0.00 0.12
free buffer waits 889 0.01 9.98 <- more time is in that event .
SQL*Net message from client 2 34.45 34.45
********************************************************************************
3.AWR wait event : (one hour awr show )
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tota Wait % DB
Event Waits Time Avg(ms) time Wait Class
------------------------------ ------------ ---- ------- ------ ----------
free buffer waits 225,109 5009 22 67.9 Configurat
enq: TX - row lock contention 1 2388 2.4E+06 32.4 Applicatio
IOStat by Function summary DB/Inst: PISA/pisa Snaps: 30584-30585
-> 'Data' columns suffixed with M,G,T,P are in multiples of 1024
other columns suffixed with K,M,G,T,P are in multiples of 1000
-> ordered by (Data Read + Write) desc
Reads: Reqs Data Writes: Reqs Data Waits: Avg
Function Name Data per sec per sec Data per sec per sec Count Tm(ms)
--------------- ------- ------- ------- ------- ------- ------- ------- -------
Buffer Cache Re 42.2G 730.4 11.954M 0M 0.0 0M 2642.4K 0.2
DBWR 0M 0.0 0M 27.8G 775.3 7.855M 1930 1489.2 <-dbwr avg is more high avg is 14*9ms
Others 11.3G 13.0 3.205M 10.8G 4.2 3.061M 62.2K 4.0
LGWR 50M 0.9 .014M 10.9G 5.4 3.096M 26.5K 16.5
Direct Writes 0M 0.0 0M 0M 0.0 0M 5 0.0
Streams AQ 0M 0.0 0M 0M 0.0 0M 13 7.2
TOTAL: 53.6G 744.3 15.172M 49.5G 784.9 14.012M 2733.1K 1.5
------------------------------------------------------
Tablespace IO Stats DB/Inst: PISA/pisa Snaps: 30584-30585
-> ordered by IOs (Reads + Writes) desc
Tablespace
------------------------------
Av Av Av 1-bk Av 1-bk Writes Buffer Av Buf
Reads Rds/s Rd(ms) Blks/Rd Rds/s Rd(ms) Writes avg/s Waits Wt(ms)
------- ------- ------- ------- ------- ------- ------- ------- -------- -------
TS_db_DATA
1.4E+06 375 0.4 3.1 2.5E+06 364.9 0 703 2,747 0.3
SYSAUX
5.9E+05 164 0.0 1.1 580 161.8 0 0 1,800 0.2
UNDOTBS1
1.3E+05 36 0.1 1.0 4.0E+05 35.6 0 110 2,135 20.7 <-avg buf wat is 20.7
---workaourd:
change
db_writer_processes integer
1
to
10
DB buffer bussy wait 分析一例的更多相关文章
- web服务器、app（应用）服务器、DB后端性能瓶颈和分析
性能测试day07_性能瓶颈和分析 https://www.cnblogs.com/leixiaobai/p/9463748.html 其实如果之前都做的很到位的话,那么再加上APM工具(dynaTr ...
- CVE-2016-10190 FFmpeg Http协议 heap buffer overflow漏洞分析及利用
作者:栈长@蚂蚁金服巴斯光年安全实验室 -------- 1. 背景 FFmpeg是一个著名的处理音视频的开源项目,非常多的播放器.转码器以及视频网站都用到了FFmpeg作为内核或者是处理流媒体的工具 ...
- CVE-2016-10191 FFmpeg RTMP Heap Buffer Overflow 漏洞分析及利用
作者:栈长@蚂蚁金服巴斯光年安全实验室 一.前言 FFmpeg是一个著名的处理音视频的开源项目,使用者众多.2016年末paulcher发现FFmpeg三个堆溢出漏洞分别为CVE-2016-10190 ...
- netty(六) buffer 源码分析
问题 : netty的 ByteBuff 和传统的ByteBuff的区别是什么? HeapByteBuf 和 DirectByteBuf 的区别 ? HeapByteBuf : 使用堆内存,缺点 ,s ...
- Tomcat系统部署启动问题分析一例[sudo 启动]
今天的系统获取新的版本后部署时突然tomcat无法启动,而比较版本的变化内容,也就是几个jsp和js文件的变化,对于web.xml等都没有调整. 这个问题很是奇怪,下面把步骤总结一下,以避免类似的问题 ...
- Hibernate内存溢出分析一例
公司业务系统在进行压力测试时,压测24小时后系统发生内存溢出.经过分析读dump文件,发现org.hibernate.stat.StatisticsImpl类的hashmap类型的变量存储了大量数据( ...
- 【慕课网实战】八、以慕课网日志分析为例 进入大数据 Spark SQL 的世界
用户行为日志:用户每次访问网站时所有的行为数据(访问.浏览.搜索.点击...) 用户行为轨迹.流量日志 日志数据内容: 1)访问的系统属性: 操作系统.浏览器等等 2)访问特征:点击的ur ...
- golang trace 分析 简例
今天,通过一个例子,一方面熟悉trace在自定义范围内的分析,另一方面golang 在协程调度策略上的浅析. Show Code // trace_example.go package main im ...
- 新產品SWOT分析實例
推出新产品需要解决四个行销支柱: 价格 产品 促销 销售地点 要分析这些方面,请检查您的优势.劣势.机会和威胁,以帮助您在运行第一个广告或举行第一次促销之前将风险降至最低,并最大限度地利用资源.SWO ...
随机推荐
- iOS国际化:NSLocalizedString的使用
因为iOS和XCode版本号更新得太快的原因,导致网上非常多文章都失去了时效性,或许再过两三个月我这篇文章也将走上这条路,但起码能够让现阶段看到的人对iOS的国际化有个比較清楚的认识. NSLocal ...
- Visual Studio VS如何修改代码字体
工具-选项-环境-字体和颜色
- The 2014 ACM-ICPC Asia Mudanjiang Regional Contest 【部分题解】
2014牡丹江亚洲区域赛邀请赛 B题:图论题目 题解:这里 K题:想法题 分析:两种变化.加入和交换.首先:星号是n的话最少须要的数字是n+1,那么能够首先推断数字够不够,不够的话如今最前面添数字,假 ...
- 【Mongodb教程 第十四课 】MongoDB 投影
mongodb 投影意思是只选择必要的数据而不是选择一个文件的数据的整个.如果一个文档有5个字段,需要显示只有3个,然后选择其中只有3个字段. find() 方法 MongoDB 的find()方法, ...
- Cookie防伪造防修改 电商课题：cookie防篡改
主要防止非法用户修改cookie信息,以及cookie的超时时间 传统cookie存储,Cookie(name, value),value很容易就被篡改. 防修改cookie存储,Cookie(nam ...
- github的提交源码到服务器
github是现代的代码库,各种牛人,各种开源,也是现在大公司招聘的一个考察点, 这里介绍一下怎样把本地源码提交到github上. 首先我们需要在github上创建一个respository. 2,输 ...
- swift语言初见
下面是swift得基础语法部分内容 // main.swift // helloSwift // // Created by cyteven on 14-7-23. // Copyright ...
- Spring简单实现数据源的动态切换
Spring简单实现数据源的动态切换: 1. 创建一个数据源切换类: 2. 继承AbstractRoutingDataSource,创建多数据源路由类,并注入到spring的配置文件中: 3. AOP ...
- 省市区三级-javabean和mybatis
bean: package com.baiwang.moirai.model.sys; import com.fasterxml.jackson.annotation.JsonInclude; /** ...
- [IMX6DL][Android4.4] 电池低电量告警提示【转】
本文转载自:http://blog.csdn.net/kris_fei/article/details/51789964 之前版本的电池电量低是通过发送 intent ACTION_BATTERY_L ...