`

共享内存段异常引起查询慢的分析处理

阅读更多

情的起因是系统的最终用户反映某些查询功能比较慢。简单地看了一下主机的负载以及数据库的性能状况,没发现什么异常,甚至可以说系统相当地轻闲。

  那问题出在哪?我首先观察到内存的使用率相当地高,达到99%。但是从操作上看,速度还没受到影响。不过很快想到,这个系统某些模块,用了短连接,难道是监听太慢引起的?这个库启了6个监听,分别TNSPING这几个监听,有个别监听非常慢,重启监听后,查询功能比较慢的问题得到解决。

  不过之前观察到的内存的异常使用引起了我极大的注意。这套系统,平时一般都会有几十G的空闲内存,不会达到这么高的。第一反应是用ipcs命令检查一下共享内存,发现有一个异常的共享内存段,占了60多G。  

[oracle@hostname%/oracle]ipcs -ma
  IPC status from /dev/kmem as of Mon Dec 7 10:58:53 2009
  T ID KEY MODE OWNER GROUP CREATOR CGROUP NATTCH SEGSZ CPID LPID ATIME DTIME CTIME
  Shared Memory:
  m 0 0x41180809 --rw-rw-rw- root root root root 0 348 2725 2725 2:38:57 2:38:57 2:38:50
  m 1 0x4e0c0002 --rw-rw-rw- root root root root 2 61760 2725 2727 12:27:19 18:19:39 2:38:50
  m 2 0x411c0de1 --rw-rw-rw- root root root root 2 8192 2725 2727 12:27:19 2:38:50 2:38:50
  m 3 0x00a5c581 --rw------- sfmdb users sfmdb users 11 10469376 3362 3398 2:39:38 2:39:39 2:39:38
  m 4 0x4118043d --rw------- root root root root 1 4096 3410 4745 2:40:12 no-entry 2:40:12
  m 5 0x06347849 --rw-rw-rw- root root root root 1 65544 3535 6722 17:53:03 17:53:03 2:39:47
  m 1015814 0x0c6629c9 --rw-r----- root dba root dba 0 35921048 6722 6722 17:53:03 no-entry 17:53:03
  m 819207 0x491002d0 --rw-r--r-- root root root root 0 22908 3674 3674 2:39:54 2:39:54 2:39:54
  m 5472264 0x00000000 D-rw-r----- oracle dba oracle dba 6 66640334848 5508 23604 17:58:00 17:58:00 17:58:00
  m 95387657 0x0000cace --rw-rw-rw- root sys root sys 0 2 21306 21306 20:24:33 20:24:33 20:24:29
  m 35520522 0xa57bccf8 --rw-r----- oracle dba oracle dba 12231 66640334848 3231 26942 10:58:53 10:58:53 18:10:36
  [oracle@hostname%/oracle]ipcs -ma
  IPC status from /dev/kmem as of Mon Dec 7 10:58:53 2009
  T ID KEY MODE OWNER GROUP CREATOR CGROUP NATTCH SEGSZ CPID LPID ATIME DTIME CTIME
  Shared Memory:
  m 0 0x41180809 --rw-rw-rw- root root root root 0 348 2725 2725 2:38:57 2:38:57 2:38:50
  m 1 0x4e0c0002 --rw-rw-rw- root root root root 2 61760 2725 2727 12:27:19 18:19:39 2:38:50
  m 2 0x411c0de1 --rw-rw-rw- root root root root 2 8192 2725 2727 12:27:19 2:38:50 2:38:50
  m 3 0x00a5c581 --rw------- sfmdb users sfmdb users 11 10469376 3362 3398 2:39:38 2:39:39 2:39:38
  m 4 0x4118043d --rw------- root root root root 1 4096 3410 4745 2:40:12 no-entry 2:40:12
  m 5 0x06347849 --rw-rw-rw- root root root root 1 65544 3535 6722 17:53:03 17:53:03 2:39:47
  m 1015814 0x0c6629c9 --rw-r----- root dba root dba 0 35921048 6722 6722 17:53:03 no-entry 17:53:03
  m 819207 0x491002d0 --rw-r--r-- root root root root 0 22908 3674 3674 2:39:54 2:39:54 2:39:54
  m 5472264 0x00000000 D-rw-r----- oracle dba oracle dba 6 66640334848 5508 23604 17:58:00 17:58:00 17:58:00
  m 95387657 0x0000cace --rw-rw-rw- root sys root sys 0 2 21306 21306 20:24:33 20:24:33 20:24:29
  m 35520522 0xa57bccf8 --rw-r----- oracle dba oracle dba 12231 66640334848 3231 26942 10:58:53 10:58:53 18:10:36

  

ID为”5472264″的共享内存段就是异常的共享内存段。

  为什么会出现这种情况?数据库可以确定是被重启过,询问客户这套系统的DBA,的确是在头一天出现了异常然后进行了重启。至于出现了什么样的异常,为什么要重启,这里不再深入。本文只讨论怎么样来清除这个异常的共享内存段。

  由于这个内存段的NTATTCH(number of attach)为6,在HP-UX下是清理不掉的:       

1[oracle@hostname%/oracle]ipcrm -5472264
2
3  ipcrm: shmid(5472264): not found
4  [oracle@hostname%/oracle]ipcrm -5472264
5  ipcrm: shmid(5472264): not found
6
7

    这是由于还有进程attach(理解为连接吧)到这个共享内存段上。只要找到这个进程被KILL之,就会解决问题。一种简单的方法是使用lsof来找到这些进程:

  [oracle@hostname%/oracle]lsof | egrep "COMMAND|5472264"

  [oracle@hostname%/oracle]lsof | egrep "COMMAND|5472264"

  不过简单的方法,不一定效率就高。这个系统光oracle server process就有5000个以上,lsof实在很慢。所以运行几分钟就直接放弃(因为以前在这套系统上运行过lsof命令,知道要输出完结果时间比较“漫长”)。

  OK, 手工找一下吧。从上面的ipcs输出的CTIME字段看到,正常的共享内存段是18:10左右创建的,而异常的是17:58左右创建的,那么attach到这个异常共享内存段的进程应该是在18点之前创建,而在17:58左右。首先使用”ps -ef | grep defunct“,没有发现僵死进程。然后根据这样的条件,并且经过一系列筛选,得到下面的结果: 

1 [oracle@hostname%/oracle]ps -ef | grep oraclesidname | grep "17:" | grep -v "18:17" | grep -v "11:17"
2  oracle 22586 1 1 07:17:43 ? 0:31 oraclesidname (LOCAL=NO)
3  oracle 28403 1 0 09:17:38 ? 0:02 oraclesidname (LOCAL=NO)
4  oracle 22618 1 0 07:17:59 ? 0:00 oraclesidname (LOCAL=NO)
5  oracle 7539 1 0 08:17:42 ? 0:10 oraclesidname (LOCAL=NO)
6  oracle 7419 1 0 08:17:05 ? 0:00 oraclesidname (LOCAL=NO)
7  oracle 22580 1 0 07:17:42 ? 0:36 oraclesidname (LOCAL=NO)
8  oracle 7421 1 0 08:17:06 ? 0:06 oraclesidname (LOCAL=NO)
9  oracle 7537 1 0 08:17:42 ? 0:02 oraclesidname (LOCAL=NO)
10  oracle 7535 1 0 08:17:41 ? 0:00 oraclesidname (LOCAL=NO)
11  oracle 21395 1 0 17:56:49 ? 0:01 oraclesidname (LOCAL=NO)
12  oracle 22616 1 0 07:17:59 ? 0:00 oraclesidname (LOCAL=NO)
13  oracle 20786 1 0 17:54:24 ? 0:10 oraclesidname (LOCAL=NO)
14  oracle 22614 1 0 07:17:58 ? 0:00 oraclesidname (LOCAL=NO)
15  oracle 7423 1 0 08:17:06 ? 0:18 oraclesidname (LOCAL=NO)
16  [oracle@hostname%/oracle]ps -ef | grep oraclesidname | grep "17:" | grep -v "18:17" | grep -v "11:17"
17  oracle 22586 1 1 07:17:43 ? 0:31 oraclesidname (LOCAL=NO)
18  oracle 28403 1 0 09:17:38 ? 0:02 oraclesidname (LOCAL=NO)
19  oracle 22618 1 0 07:17:59 ? 0:00 oraclesidname (LOCAL=NO)
20  oracle 7539 1 0 08:17:42 ? 0:10 oraclesidname (LOCAL=NO)
21  oracle 7419 1 0 08:17:05 ? 0:00 oraclesidname (LOCAL=NO)
22  oracle 22580 1 0 07:17:42 ? 0:36 oraclesidname (LOCAL=NO)
23  oracle 7421 1 0 08:17:06 ? 0:06 oraclesidname (LOCAL=NO)
24  oracle 7537 1 0 08:17:42 ? 0:02 oraclesidname (LOCAL=NO)
25  oracle 7535 1 0 08:17:41 ? 0:00 oraclesidname (LOCAL=NO)
26  oracle 21395 1 0 17:56:49 ? 0:01 oraclesidname (LOCAL=NO)
27  oracle 22616 1 0 07:17:59 ? 0:00 oraclesidname (LOCAL=NO)
28  oracle 20786 1 0 17:54:24 ? 0:10 oraclesidname (LOCAL=NO)
29  oracle 22614 1 0 07:17:58 ? 0:00 oraclesidname (LOCAL=NO)
30  oracle 7423 1 0 08:17:06 ? 0:18 oraclesidname (LOCAL=NO)

  看上去进程号为21395和20786的进程,正好满足前面提到的条件。KILL这两个进程,检查共享内存段,发现这个异常的共享内存段自动被清除。再检查内存的使用,内存的使用率也大幅下降,回到正常状态。

分享到:
评论

相关推荐

    VxWorks任务异常处理

    4. **系统调用不当**:在中断处理中不当使用可能引起阻塞的函数,如printf、semTake等,或错误使用printf导致内存改写。 5. **增量编译问题**:Tornado增量编译偶尔会引入难以预料的异常,重新进行全量编译往往能...

    svchost.exe[1348]中发生未处理的win32异常解决办法

    win32 异常可能是由于各种原因引起的,例如代码错误、内存溢出、系统配置错误等。 为了防止 win32 异常的出现,需要遵循以下几点: 1. 安装微软官方提供的更新程序,以修复系统中的安全漏洞。 2. 及时更新操作系统...

    VxWorks系统异常分析方法.docx

    6. **系统调用不当**:在中断回调中使用可能会引起阻塞的系统调用,如`printf`,或者不恰当的内存操作,都可能导致异常。 7. **增量编译问题**:Tornado和Workbench的增量编译有时会产生意想不到的异常,全量编译...

    qt 段错误 解决方案

    5. **内存泄漏**:长期的内存泄漏可能导致可用内存耗尽,使得后续的内存分配失败,进而引起段错误。 针对这些问题,以下是一些解决Qt中段错误的策略: 1. **调试工具**:使用GDB等调试器可以帮助定位段错误发生的...

    linux部署项目常见异常大全

    ### Linux部署项目常见异常分析 #### 一、异常概述 在进行Linux环境下项目的部署与运维过程...通过以上分析与处理流程,可以有效地解决Linux部署项目中因磁盘空间不足导致的各种异常问题,提高系统的稳定性和可用性。

    共享内存系统上并行循环的容错调度

    针对这类问题,研究论文“共享内存系统上并行循环的容错调度”提出了解决方案,其目标是在出现各种硬件故障的情况下,高效地执行并行循环。论文提出了一个容错的工作窃取机制,该机制能够使并行循环执行对抗硬件故障...

    解决内存不能为real

    2. **软件冲突**:两个或多个正在运行的程序之间存在资源竞争,导致内存访问异常。 3. **系统资源不足**:系统内存或虚拟内存不足,无法满足程序的运行需求。 4. **DLL文件损坏或缺失**:DLL文件是许多程序运行的...

    操作系统(内存管理)

    文中将为您提供如何管理内存的细节,然后将进一步展示如何手工管理内存,如何使用引用计数或者内存池来半手工地管理内存,以及如何使用垃圾收集自动管理内存。 为什么必须管理内存 内存管理是计算机编程最为基本的...

    Core_Dump分析

    这个文件通常只包含异常时相关的内存信息,而不包含所有共享内存(除非环境变量CORE_NOSHM未设置)。Core文件的格式依赖于操作系统,AIX系统中的格式可以参考/usr/include/sys/core.h或相关文档。 应用进程的Core ...

    00000000000000流水线cpu修正01

    内存访问速度通常比其他CPU操作慢得多,因此这一阶段可能是流水线中的瓶颈。 5. **写回(Writeback)**:最后,执行的结果被写回到寄存器或者内存中。在写回阶段,可能需要处理结果冲突和数据转发,以避免因数据...

    ORACLE CPU 耗尽内存

    3. **调整内存参数**:合理设置SGA和PGA大小,确保数据缓冲区、共享池等组件足够大,同时避免内存泄漏。 4. **控制并发**:根据系统负载情况限制并发连接数,避免过多的并发请求导致资源争抢。 5. **检查后台进程*...

    深入浅出Linux工具与编程-进程间通信

    - **共享内存段的创建**:通常使用`shmget()`函数来创建或获取共享内存段的标识符。 - **内存映射**:可以使用`shmat()`将共享内存段映射到进程地址空间中,`shmdt()`解除映射。 - **同步问题**:虽然共享内存本身不...

    android项目内存泄露排查实用.pdf

    1. Application 对象的生命周期与整个 App 的生命周期一致,可以用来存放全局变量,但是注意不要引起内存泄露。 2. 系统给应用的 heap 堆内存是动态分配的,不够了会增加,但是有上限,约 24MB。如果长时间低于 30% ...

    day05_异常、线程-每日作业卷2

    `RuntimeException` 表示程序运行时由于逻辑错误或不完整的状态引起的异常,如空指针异常、数组越界异常等。这些异常在编译时不需要强制捕获,但如果在编写代码时能预见并处理,可以提高程序的健壮性。 【异常处理...

    Linux信号处理方法的问题

    1. **简化信号处理函数**:避免在信号处理函数中执行复杂的操作,尤其是涉及到资源释放或内存分配等可能引起重入问题的操作。 2. **单一线程处理信号**:设计一个专门的线程来处理信号,这样可以避免多线程间因信号...

    一、JVM内存区域1

    字节码解释器工作时是通过这个计数器的值选取下一条需要执行的字节码指令,分支、循环、异常处理等基础功能都需要依赖这个计数器完成。由于 Java 虚拟机的多线程是通过线程轮流切换并分配处理器执行时间的方式来实现...

    delphi dll

    同时,检查是否有异常处理机制来捕获和记录内存错误,以便更好地定位问题。进行单元测试和压力测试也可以帮助发现内存溢出问题,尤其是在长时间运行或高负载情况下。 总之,理解和解决Delphi DLL中的内存溢出问题...

    cpu打满问题分析思路

    在与硬件通信过程中抛出了I/O异常,但由于循环内的try-catch处理,异常被不断捕获并重新抛出,导致线程一直处于活跃状态,从而引起CPU使用率上升。 3. **解决方案**:在catch代码块中添加了`return`语句,中断异常...

Global site tag (gtag.js) - Google Analytics