当前位置:Gxlcms > mysql > AWR--servicestatistics

AWR--servicestatistics

时间:2021-07-01 10:21:17 帮助过:32人阅读

最近发现一个奇怪的现象,数据库报告上看负载很高,但是cpu和等待事件都很低,不知道消耗的资源跑到哪里去了? Snap Id Snap Time Sessions Cursors/Session Begin Snap: 5073 17-5月 -14 04:00:20 127 78.8 End Snap: 5074 17-5月 -14 05:13:36 363 19.5 El

最近发现一个奇怪的现象,数据库报告上看负载很高,但是cpu和等待事件都很低,不知道消耗的资源跑到哪里去了?


Snap Id
Snap Time Sessions Cursors/Session
Begin Snap: 5073 17-5月 -14 04:00:20 127 78.8
End Snap: 5074 17-5月 -14 05:13:36 363 19.5
Elapsed: 73.27 (mins)
DB Time: 1,196.25 (mins)

Top 5 Timed Events

Event Waits Time(s) Avg Wait(ms) % Total Call Time Wait Class
latch: library cache 3,174 6,933 2,184 9.7 Concurrency
latch free 977 6,530 6,684 9.1 Other
latch: shared pool 4,021 1,929 480 2.7 Concurrency
cursor: pin S wait on X 82,902 1,620 20 2.3 Concurrency
CPU time 1,073 1.5

Service Statistics

  • ordered by DB Time
    Service Name DB Time (s) DB CPU (s) Physical Reads Logical Reads
    SYS$USERS 67,080.30 454.30 43,604 15,183,498
    scmis 4,523.20 588.30 0 22,868,201
    SYS$BACKGROUND 0.00 0.00 109 77,783

    可以看到数据库软件消耗的资源不多。

    找到问题症结:再看servicestatistics总的SYS$USERS消耗最多,这个是何方圣神呢?官方文档的解释:the SYS$USERS serviceis the default service name used when a user session is established withoutexplicitly identifying its service name。就是说SYS$USERS这是一个缺省的服务名,当用户的session建立的时候没有明确的标示符。

    那说明此时有其他的服务在数据库服务器上跑,只有用操作系统层面上做诊断,用shell写一个top的脚本监控一下,是哪个进程导致。最后诊断出是数据库服务器在某个时间段不响应,简单的说是硬件的问题。

人气教程排行