精华内容
下载资源
问答
  • 背景: 公司有一个通讯系统,主要是通讯数据到客户端程序所指定的数据库,目前支持sqlserver、mysql和oracle三种类型的数据库,此篇主要记录一次oracle数据库占用CPU飙高的问题。 症状: oracle支持上线后,数家...

        背景:

        公司有一个通讯系统,主要是通讯数据到客户端程序所指定的数据库,目前支持sqlserver、mysql和oracle三种类型的数据库,此篇主要记录一次oracle数据库占用CPU飙高的问题。

        症状:

        oracle支持上线后,数家客户反馈他们的oracle数据库所在的服务器在程序运行一段时间后CPU飙升,此时查看数据库连接,发现我们的程序占用了大量的数据库连接,有时连接占满后导致在本地用plsql都连不上数据库,会报ORA-00020: maximum number of processes (1000) exceeded错误,严重影响了所有该数据库的使用者

        解决过程:

        由于是之前解决的,某些细节方面可能有疏漏,根据记忆写下大概的解决过程

        一、首先在数据库连接满的情况下,由于登录不上oracle,需要先解决登录oracle的问题,通过查资料发现可以先杀掉一些oracle线程,ps -ef|grep LOCAL   --可以看到很多连接

    删除前10条LOCAL=NO的数据库连接:

    ps -ef|grep LOCAL=NO|grep -v grep|awk '{print $2}'|head|xargs kill -9

    删除过多的连接后,使用plsql登录进数据库

    注:关于LOCAL=NO的解释,可参看此文章Oracle 服务器 进程中的 LOCAL=NO 和 LOCAL=YES

        二、查看使用jdbc连接数据库的程序产生的版本数(由于测试环境重现了该问题,所以确定jdbc连接的只有我们的程序)

    select sql_id,version_count,SQL_TEXT from v$sqlarea where version_count>= 0 AND module = 'JDBC Thin Client' order by 2 desc ;

        三、找到版本较高的前几个sqlid,查看每次接收的绑定变量的类型,每次的区别在哪里

    select position,datatype_string,value_string,LAST_CAPTURED from v$sql_bind_capture where sql_id='amnppbv67qak4' --and rownum<=1000 AND value_string IS NOT NULL;

    可以发现相同sql的不同版本差异都在绑定变量的datatype_string值不同造成的,比如同样的字段,同样的绑定变量,第一次update时,传进来的值为null,则此时oracle会自动使用VARCHAR2(32)来接收,若下次传进来的值大于VARCHAR2(32)长度,则oracle会使用VARCHAR2(128)来接收(参考BIND_MISMATCH导致过多VERSION COUNT的问题),则针对这个sql则会重新硬解析,生成一个新的版本和执行计划,此处会占用大量的服务器资源。

        四、此时为了数据库可以尽快的恢复运转,可执行如下sql来清除shared_pool,执行后数据库可暂时恢复正常(好像执行该语句需先停止其他程序对该数据库的访问,否则会一直卡在那里):

    alter system flush shared_pool;

    综上,出现该问题的原因主要有两种情况:

        1.待insert或update的表中有较多可空字段,jdbc执行语句时,传进去绑定变量时使用了statement.setObject()方法,此时即使是非字符型的字段,oracle也会使用VARCHAR2(32)来接收,而之后传进具体的值时,oracle就会根据字段类型使用新的类型来接收该绑定变量的值,同时硬解析生成新版本和执行计划;

        2.通讯某些字符型字段特别多的表,且字段长度不固定的情况下,较大可能出现这种问题。

        解决方法:

        针对原因1,目前在程序中做了修改,除了clob等特殊类型外,日期或数值等类型字段,都统一使用statement.setString()方法去赋值,oracle可以自动转化为相对应的类型入库;

        针对原因2,没有特别好的方法,参考BIND_MISMATCH导致过多VERSION COUNT的问题,设置了oracle接收绑定变量时,直接使用VARCHAR2(2000)来接收

    alter system set events '10503  trace name context forever ,level 2000'

    此解决方法不是特别妥当,不过确实可以解决该问题,至于时候会引起其他问题,暂时还未发现。

        该问题其实是由oracle的版本BUG引起的(截自由 bind_mismatch 引起的 大量 version_count 问题)


    故升级oracle版本自然是最稳妥的解决方案,不过由于有些客户可能不愿意升级,所以此处提供了自己的解决方案,具体效果还需后续观察





    展开全文
  • sql占用大量cpu,使用SQL Server Profiler获取的记录用数据库引擎优化顾问进行分析后它提供的建议怎么使用? SET ANSI_PADDING ON CREATE NONCLUSTERED INDEX [_dta_index_tbl_shangshu2_7_2118298606__K3_K2] ON...
  • Oracle数据库CPU占用过高

    千次阅读 2019-05-20 17:37:38
    运行在Windows上的Oracle开发库的oracle进程CPU使用率保持在99%,服务器和数据库均反应缓慢。 二、排查思路 可能造成CPU使用率高的情况有:大量排序、大量SQL解析、全表扫描、Oracle Bug等。因此希望找到占用CPU较...

    一、问题描述

    运行在Windows上的Oracle开发库的oracle进程CPU使用率保持在99%,服务器和数据库均反应缓慢。

    二、排查思路

    可能造成CPU使用率高的情况有:大量排序、大量SQL解析、全表扫描、Oracle Bug等。因此希望找到占用CPU较高的进程ID(UNIX或LINUX)或线程ID(Windows)来找到对应的SQL语句,以分析问题的原因。

    三、处理步骤

    1. 下载process explorer工具,用于查看Windows环境下的进程和线程信息。

    2. 双击oracle.exe进程,查看oracle的线程信息,按照CPU使用率倒序排序,找到占用CPU较高的TID。(如在UNIX或LINUX系统中,使用top命令即可获得占用CPU较高的进程ID,使用进程ID去数据库中查找对应信息即可)

    3. 使用上面找到的TID代入下面的SQL查询对应的SQL语句或会话信息。


    SELECT sql_text FROM v$sqltext a WHERE (a.hash_value, a.address) IN (SELECT DECODE(sql_hash_value, 0, prev_hash_value, sql_hash_value),DECODE(sql_hash_value, 0, prev_sql_addr, sql_address) FROM v$session b WHERE b.paddr =(SELECT addr FROM v$process c WHERE c.spid = '&pid')) ORDER BY piece ASC;


    select id,serial# ,username,osuser,machine,program,process,to_char(logon_time,'yyyy-mm-dd hh24:mi:ss') logon from v$session where paddr in ( select addr from v$process where spid in('&pid'));

    4. kill掉查出的会话,记录查出的SQL语句待后续分析。


    四、总结:

    在进行第三步的时候遇到状况:使用找出的TID在数据库中查不到对应的SQL和会话信息。为先恢复数据库服务,直接kill了占用CPU较高的几个线程,后续通过分析AWR和ASH报告推测本次故障与数据库中几个涉及临时表创建和操作的存储过程有关,在存储过程执行中有大量的全表扫描和直接路径读并伴随大量的物理读操作。
    --------------------- 
    作者:韩小昱 
    来源:CSDN 
    原文:https://blog.csdn.net/hrbhanyu/article/details/54892014 
    版权声明:本文为博主原创文章,转载请附上博文链接!

    展开全文
  • 环境信息 数据库版本:11.2.0.2 RAC 操作系统:AIX 6.1 现象描述 通过监控发现服务器负载相对以前上升20-30% 诊断过...

    环境信息

     

    数据库版本:11.2.0.2 RAC

    操作系统:AIX 6.1

     

     

    现象描述

     

    通过监控发现服务器负载相对以前上升20-30%

     

     

    诊断过程

    查看AWR没有发现有特殊的等待事件或SQL

    Top 5 Timed Foreground Events

    Event

    Waits

    Time(s)

    Avg wait (ms)

    % DB time

    Wait Class

    DB CPU

     

    5,297

     

    37.04

     

    db file sequential read

    546,298

    2,658

    5

    18.59

    User I/O

    gc current block 2-way

    2,593,242

    2,656

    1

    18.57

    Cluster

    log file sync

    1,512,801

    1,480

    1

    10.35

    Commit

    gc cr block 2-way

    479,451

    470

    1

    3.29

    Cluster

     

     

     

    再查看服务器,其中一个节点有个进程一直占用大量CPU,而且没有释放的迹象,进程的名称名为ora_o000_xxxxprod1

     

    Topas Monitor for host:    p520db1              EVENTS/QUEUES    FILE/TTY

    Fri Jun 14 10:33:29 2013   Interval:  2         Cswitch    7961  Readch   354.8K

                                                    Syscall   22757  Writech   16898

    CPU  User%  Kern%  Wait%  Idle%                 Reads       143  Rawin         0

    ALL   29.0    3.3    1.7   66.1                 Writes       83  Ttyout      438

                                                    Forks         2  Igets         0

    Network  KBPS   I-Pack  O-Pack   KB-In  KB-Out  Execs         3  Namei       223

    Total    49.3     92.8    68.3    29.3    20.0  Runqueue    3.0  Dirblk        0

                                                    Waitqueue   0.0

    Disk    Busy%     KBPS     TPS KB-Read KB-Writ                   MEMORY

    Total     7.0    302.7    29.0   231.4    71.3  PAGING           Real,MB   31615

                                                    Faults     2355  % Comp     75

    FileSystem        KBPS     TPS KB-Read KB-Writ  Steals        0  % Noncomp  24

    Total            123.0   134.2  117.7    5.3    PgspIn        0  % Client   24

                                                    PgspOut       0

    Name            PID  CPU%  PgSp Owner           PageIn        0  PAGING SPACE

    oracle      8061062  24.6  14.9 oracle          PageOut       4  Size,MB   17920

    octssd.b    4390912   0.5  20.3 root            Sios          4  % Used      0

    oracle      4587816   0.5 1825.2 grid                            % Free    100

    gipcd.bi    3670122   0.5  31.1 grid            NFS (calls/sec)

    oraroota   10158456   0.5  48.0 root            SerV2         0  WPAR Activ    0

    evmd.bin    4194570   0.5  46.3 grid            CliV2         0  WPAR Total    0

    crsd.bin    2884034   0.5  83.9 root            SerV3         0  Press: "h"-help

    ohasd.bi    9241020   0.4  99.1 root            CliV3         0         "q"-quit

    gil          459056   0.3   0.9 root 

    oraagent   10224030   0.3 105.1 grid 

    oracle      7536726   0.3  46.0 oracle

    oraagent    8323190   0.3  54.2 oracle

    oracle      9699748   0.2  20.0 grid 

    oraagent    4063586   0.1  83.4 grid 

    oracle      4980778   0.1  27.2 grid 

    oraroota    8388684   0.1  54.8 root 

    oracle      9896076   0.1  30.1 oracle

    oracle      4849714   0.1  19.8 grid

    dtgreet      852334   0.1   1.3 root 

    oracle      5308858   0.0  16.4 oracle

     

    bash-3.00$ ps -ef|grep 8061062                         

      oracle  8061062        1 120   Sep 29      - 13907:17 ora_o000_xxxxprod1

      oracle  1966452  6357172   0 10:36:18  pts/0  0:00 grep 8061062

     

     

     

     

    通过下面进程号我们看到一直在执行下面SQL,可以看到这个SQL是数据库自己的SQL

     

    SQL> SELECT /* +RULE */

      2          Q.SQL_TEXT,  Q.PIECE,

      3          DECODE(S.SQL_HASH_VALUE, 0, 'Last', 'Current') STAUTS

      4     FROM GV$SQLTEXT Q, GV$SESSION S, GV$PROCESS P

      5    WHERE Q.HASH_VALUE(+) = DECODE(S.SQL_HASH_VALUE,

      6                                   0,

      7                                   S.PREV_HASH_VALUE,

      8                                   S.SQL_HASH_VALUE)

      9      AND Q.ADDRESS(+) =

     10          DECODE(S.SQL_HASH_VALUE, 0, S.PREV_SQL_ADDR, S.SQL_ADDRESS)

     11      AND S.PADDR = P.ADDR

     12      AND P.SPID = 8061062

     13      order by piece

     14  ;

     

    SQL_TEXT                                                              PIECE STAUTS

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

    select job, nvl2(last_date, 1, 0) from sys.job$ where (((:1 <= n          0 Last

    ext_date) and (next_date <= :2))    or  ((last_date is null) and          1 Last

     (next_date < :3))) and (field1 = :4 or (field1 = 0 and 'Y' = :5          2 Last

    )) and (this_date is null) and ((dbms_logstdby.db_is_logstdby =           3 Last

    0 and job < 1000000000) or  (dbms_logstdby.db_is_logstdby = 1 an          4 Last

    d job >= 1000000000)) order by next_date, job                             5 Last

                                                                                Last

     

    7 rows selected

     

    SQL>

     

     

    查看这个session的等待事件

     

    SQL>  select event from v$session_wait where sid=1707;

     

    EVENT

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

    class slave wait

     

    SQL>

     

     

     

    根据这个等待事件,我们发现为Bug 10285394

     

     

     

    解决方案

     

    打上补丁10285394

     

     

     

    这个Bug相关的说明

     

    ora_o00n Process High CPU Usage in 11.2.0.2 [ID 1459376.1]

    To Bottom

    Modified:Jan 11, 2013 Type:PROBLEM Status:PUBLISHED Priority:2

    Comments (0)

    In this Document

    Symptoms

     

    Cause

     

    Solution

     

    References

    1              Applies to:

    Oracle Server - Enterprise Edition - Version 11.2.0.2 to 11.2.0.2.0 [Release 11.2]
    Information in this document applies to any platform.

    2              Symptoms

    11.2.0.2 database on ASM, the ora_o00n process consumes high CPU: 

    • top command output

      PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND          
      
     2921 oracle    25   0 1715m  17m  15m R 99.5  0.1 658:32.91 ora_o001_trng

     

    • Oracle process dump:

    Call stack:  .. dbgtTrc_int ksvreceive kfncPoolCb ksvrdp opirip ..
     
    Current Wait Stack:

         0: waiting for 'class slave wait'
            slave id=0x0, =0x0, =0x0
            wait_id=139 seq_num=140 snap_id=1
            wait times: snap=358705 min 17 sec, exc=358705 min 17 sec, total=358705 min 17 sec

     

    • OS truss/strace command shows the process is spinning on OS call gettimeofday

    3              Cause

    Due to bug 10285394

    Multiple duplicates open: bug 13767869 bug 13789248 bug 13767461 bug 13918332 bug 13952464 bug 12929268  bug 12671004 bug 13363390 bug 14044697

    4              Solution

    Refer to note 10285394.8 for more info about the bug. 

    5              References

    BUG:12929268 - HIGH CPU ON ORA_O00N PROCESS

     

     

    来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/21605631/viewspace-765425/,如需转载,请注明出处,否则将追究法律责任。

    转载于:http://blog.itpub.net/21605631/viewspace-765425/

    展开全文
  • Oracle数据库经常会遇到CPU利用率很高的情况,这种时候大都是数据库中存在着严重性能低下的SQL语句,这种SQL语句大大的消耗了CPU资源,导致整个系统性能低下。当然,引起严重性能低下的SQL语句的原因是多方面的,...

    Oracle数据库经常会遇到CPU利用率很高的情况,这种时候大都是数据库中存在着严重性能低下的SQL语句,这种SQL语句大大的消耗了CPU资源,导致整个系统性能低下。当然,引起严重性能低下的SQL语句的原因是多方面的,具体的原因要具体的来分析,下面通过一个实际的案例来说明如何来诊断和解决CPU利用率高的这类问题。

    操作系统:Linux7.0

    数据库:Oracle11.2.0.4

    问题描述:现场工程师汇报数据库非常慢,几乎所有应用操作均无法正常进行。不久后,系统断开连接,宕机。

    首先重启系统后,启动数据库。执行top发现CPU资源几乎消耗殆尽,存在很多占用CPU很高的进程,而内存和I/O都不高,具体如下:

    last pid: 26136;  load averages:  8.89,  8.91,  8.12                                                                      

    216 processes: 204 sleeping, 8 running, 4 on cpu

    CPU states:  0.6% idle, 97.3% user,  1.8% kernel,  0.2% iowait,  0.0% swap

    Memory: 8192M real, 1166M free, 14M swap in use, 8179M swap free

    PID USERNAME THR PRI NICE  SIZE   RES STATE   TIME    CPU COMMAND

    25725 oracle     1  50    0 4550M 4508M cpu2   12:23 11.23% oracle

    25774 oracle     1  41    0 4550M 4508M run    14:25 10.66% oracle

    26016 oracle     1  31    0 4550M 4508M run     5:41 10.37% oracle

    26010 oracle     1  41    0 4550M 4508M run     4:40  9.81% oracle

    26014 oracle     1  51    0 4550M 4506M cpu6    4:19  9.76% oracle

    25873 oracle     1  41    0 4550M 4508M run    12:10  9.45% oracle

    25723 oracle     1  50    0 4550M 4508M run    15:09  9.40% oracle

    26121 oracle     1  41    0 4550M 4506M cpu0    1:13  9.28% oracle

    25745 oracle     1  41    0 4551M 4512M run     9:33  9.28% oracle

    26136 oracle     1  41    0 4550M 4506M run     0:06  5.61% oracle

      409 root      15  59    0 7168K 7008K sleep 173.1H  0.52% picld

    25653 oracle     1  59    0 4550M 4508M sleep   1:01  0.46% oracle

    25565 oracle     1  59    0 4550M 4508M sleep   0:07  0.24% oracle

    25703 oracle     1  59    0 4550M 4506M sleep   0:08  0.13% oracle

    25701 oracle     1  59    0 4550M 4509M sleep   0:23  0.10% oracle

    于是先查看数据库的告警日志ALERT文件,并没有发现有什么错误存在,日志显示数据库运行正常,排除数据库本身存在问题。

    然后查看这些占用CPU资源很高的Oracle进程究竟是在做什么操作,使用如下SQL语句:

    select sql_text,spid,v$session.program,process  from

    v$sqlarea,v$session,v$process

    where v$sqlarea.address=v$session.sql_address

    and v$sqlarea.hash_value=v$session.sql_hash_value

    and v$session.paddr=v$process.addr

    and v$process.spid in (PID);

    用top中占用CPU很高的进程的PID替换脚本中的PID,得到相应的Oracle进程所执行的SQL语句,发现占用CPU资源很高的进程都是执行同一个SQL语句:

     

    select username "username", to_char(timestamp,'DD-MON-YYYY HH24:MI:SS') "time_stamp", action_name "statement", os_username "os_username", userhost "userhost", returncode||decode(returncode,'1004','-Wrong Connection','1005','-NULL Password','1017','-Wrong Password','1045','-Insufficient Priviledge','0','-Login Accepted','--') "returncode" from sys.dba_audit_session where (sysdate - timestamp)*24 < 1 and returncode <> 0 order by timestamp;

     

    基本上可以肯定是这个SQL引起了系统CPU资源大量被占用,那究竟是什么原因造成这个SQL这么大量占用CPU资源呢,从上面的SQL语句中我们可以看到sys.dba_audit_session这张表,由此可以确定是由于审计的原因导致数据库占用大量CPU。

    查看数据库审计信息:

    SQL> show parameter audit

     

    NAME                                 TYPE        VALUE

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

    audit_file_dest                      string      /u01/app/oracle/admin/orcl/adump

    audit_sys_operations                 boolean     FALSE

    audit_syslog_level                   string

    audit_trail                          string      DB

    可以看到数据库审计为开启状态,并且将audited record的存放在数据库里(sys.aud$)中。

    问题处理方法:

    1.如果审计不是必须的,可以关掉审计功能;

    SQL> alter system set audit_trail=none scope=spfile;

    SQL>showdown immediate;

    SQL>startup

    2.删除已有的审计信息

    可以直接truncate表aud$,

    或者采取dbms_audit_mgmt来清除。

    3.或者将aud$表移到另外一个表空间下,以减少system表空间的压力和被撑爆的风险。

    附:11g中有关audit_trail参数的设置说明:

    AUDIT_TRAIL

    Property Description
    Parameter type String
    Syntax AUDIT_TRAIL = { none | os | db [, extended] | xml [, extended] }
    Default value none
    Modifiable No
    Basic No

     

    AUDIT_TRAIL enables or disables database auditing.

    Values:

    • none

      Disables standard auditing. This value is the default if the AUDIT_TRAIL parameter was not set in the initialization parameter file or if you created the database using a method other than Database Configuration Assistant. If you created the database using Database Configuration Assistant, then the default is db.

    • os

      Directs all audit records to an operating system file. Oracle recommends that you use the os setting, particularly if you are using an ultra-secure database configuration.

    • db

      Directs audit records to the database audit trail (the SYS.AUD$ table), except for records that are always written to the operating system audit trail. Use this setting for a general database for manageability.

      If the database was started in read-only mode with AUDIT_TRAIL set to db, then Oracle Database internally sets AUDIT_TRAIL to os. Check the alert log for details.

    • db, extended

      Performs all actions of AUDIT_TRAIL=db, and also populates the SQL bind and SQL text CLOB-type columns of the SYS.AUD$ table, when available. These two columns are populated only when this parameter is specified.

      If the database was started in read-only mode with AUDIT_TRAIL set to db, extended, then Oracle Database internally sets AUDIT_TRAIL to os. Check the alert log for details.

    • xml

      Writes to the operating system audit record file in XML format. Records all elements of the AuditRecord node except Sql_Text and Sql_Bind to the operating system XML audit file.

    • xml, extended

      Performs all actions of AUDIT_TRAIL=xml, and populates the SQL bind and SQL text CLOB-type columns of the SYS.AUD$table, wherever possible. These columns are populated only when this parameter is specified.

    You can use the SQL AUDIT statement to set auditing options regardless of the setting of this parameter.

    展开全文
  • 在日常的数据库运维中,操作系统CPU使用率一直是我们衡量系统负载的一个比较贴切的指标,例如USER%可以更好的反馈数据库CPU的使用情况,进而我们再次去数据库中找出导致CPU消耗高的源头,wa%可以反馈IO等待消耗的...
  • OEM大量占用cpu解决方法

    千次阅读 2013-06-14 12:41:16
    登陆到数据库服务器上,使用top命令,看到有一个进程perl占用CPU为100%,是属于oracle用户的。  2. 直接kill -9,可惜的是过了几秒钟此进程有启动了,又占用了100%的CPU。  3. 关闭emctl stop dbconsole,然后再...
  • 一、dllhost占用大量内存的可能原因: 1 、感染了的病毒用杀毒软件好好查一查2、web程序问题A、在你的程序中,没有及时关闭数据库和记录集的连接很容易造成内存泄漏和sql进程死锁。所以写程序时,一定要尽快释放系统...
  • us:用户占用cpu百分比,如果长期高于50%,需检查会话中是否存在大量表扫描,检查会话快照中耗时长的会话操作和检查上下文快照中,存在tbscan的上下文操作。如果存在表扫描,可以使用添加索引进行优化。 sy:...
  • 1:使用 MicrosoftJet 数据库引擎 Web 应用程序可能停止响应负载,造成假死: 原因:发生此问题是因为 Jet 数据库引擎中存在缺陷。 Microsoft Windows Server 2003 上只会出现此问题。 在 Windows Server 2003, ...
  •  运行在Windows上的Oracle开发库的oracle进程CPU使用率保持在99%,服务器和数据库均反应缓慢。  二、排查思路  可能造成CPU使用率高的情况有:大量排序、大量SQL解析、全表扫描、Oracle Bug等。因此希望找到...
  • 转载自:... 很多时候由于异常或程序错误会导致个别进程占用大量系统资源,需要结束这些进程,通常可以使用以下命令Kill进程: alter system kill session 'sid,serial#'; 但是
  • 由于dba离职,所以公司所有的oracle数据库服务器我先兼职管理,今天登陆某省的数据库,发现ssh登陆30秒左右才进入,之后查看了一下负载与内存,具体情况如下图: 负载: 没有见过这样高的负载,以前见过最多的就是...
  • 下面是找出哪个数据库占用大量cpu
  • 很多时候由于异常或程序错误会导致个别进程占用大量系统资源,需要结束这些进程,通常可以使用以下命令Kill进程: alter system kill session sid,serial#; 但是此命令释放资源极为缓慢,具体可以参考:Or
  • 一、通过top命令可以看到会话PID19237占用大量CPU Tasks:233total,2running,231sleeping,0stopped,0zombie Cpu0...
  • mysql 占用大量写I/O

    2018-10-22 09:18:00
    zabbix告警,发现某台存放监控数据的数据库主机CPU的IOwait较高,一直持续较长时间。 登录服务器查看磁盘IO发现队列高达90%多,而且经常反复如此 通过iotop查看发现占用io较大的进程是mysql 登录mysql查看show ...
  • Mysql占用大量写I/O

    万次阅读 2017-03-07 15:06:59
    早上收到zabbix告警,发现某台存放监控数据的数据库主机CPU的IOwait较高,一直持续较长时间。 登录服务器查看磁盘IO发现队列高达90%多,而且经常反复如此 通过iotop查看发现占用io较大的进程是mysql 登录mysql查看...
  • CPU占用99%

    2017-03-03 16:34:00
    晚间迁移数据库后,第二天下午来调优,发现CPU占用达到惊人的99%,如下: 分析15:00-16:00期间AWR报告,发现SQL硬解析严重,如下: 每秒硬解析达到69.9次,library hit%太低86%,如下: 此时的共享池达到了...
  • 出现该问题一般为程序方面问题,如程序采用...查看系统临时文件是否过多,mysql数据库的临时文件默认存到了c:/windows/temp,导致累积了几万甚至上百万的小文件,压垮系统盘。 del . 删除所有文件 2.PHP是一种广泛...
  • 答:首先使用top命令查看是否是mysql服务占用导致的,如果不是,那就直接杀死,如果是,进入数据库查看是否有高资源的进程,找出消耗高的,再查看原因(执行计划是否准确,index是否缺失,是否是数据量太大)来进行...

空空如也

空空如也

1 2 3 4 5 ... 18
收藏数 356
精华内容 142
关键字:

数据库占用大量cpu