系统应用服务器内存溢出解决报告

第一篇：系统应用服务器内存溢出解决报告

XXX系统应用服务器内存溢出解决报告

xxxx股份有限公司

2010.9

目录

第一章 问题现象与分析................................................................................2

1.1、问题现象.....................................................................................2 1.2、通常导致这种现象的原因..................................................................2 1.3、xxx社保宕机现象对比分析...............................................................3 第二章

解决方法路线图..............................................................................4

2.1 jvm的调整...................................................................................4 2.2 减少jvm内存使用..........................................................................5 2.2.1 加快db访问速度，减少中间件并发业务量.......................................5 2.2.2 限制sql返回结果集..................................................................6 2.2.3 减少业务会话中存放的对象.........................................................6 2.3 补救措施......................................................................................6 第三章、解决结果与进一步建议......................................................................6

3.1 解决结果......................................................................................6 3.2 进一步建议...................................................................................7

第一章 问题现象与分析

1.1、问题现象

XXX应用服务器经常有内存溢出、系统没有响应的现象，尤其在每月的月末最为明显。目前的应用服务器有三种类型，其中ibm和linux应用服务器报告频繁出现内存溢出或没有响应的现象，hp unix应用服务器相稳定。在出现问题期间Weblogic无法响应任何客户端请求，大量请求加载到了这台没有响应的Server上，最后只有杀掉并重启这台应用服务器。

1.2、通常导致这种现象的原因

WLS Server 没响应可能的几种原因：

xxxx股份有限公司

1、繁重的I/O，呼叫DB时间过长导致中间件内存耗尽，server没有响应。

2、程序死循环，loop－backs，这种情况cpu很忙，系统没有响应。

3、连接到外部server，没响应，由于网络等原因 4、2个以上的执行者同步死锁

5、业务量过大，全部线程都被占用，出现队列等待现象

6、读写本地I/O，发生阻塞

WLS Server 宕机的原因：

    OutOfMemory JNI程序 jvm的bug os的bug 1.3、xxx社保宕机现象对比分析

 应用服务器没有响应分析

通过初步判断，对于xxx应用服务器没有响应的情况可以做如下排出法解决： ――程序死循环

这种情况会导致cpu非常繁忙，而通过目前观察，每次系统没响应的时候，cpu没有一直100%忙，另外，对出现问题时的java core分析没有发现这类线程，因此可以基本排除这种可能。

――连接到外部server，没响应，由于网络等原因

目前我们的业务基本都是直接通过中间件访问数据，没有通过应用服务器间调用或多数据库调用的，基本排除这种可能。――2个以上的执行者同步死锁

这种情况有可能，但比较难找，一般都是业务高峰的时候才有可能出现，跟应用人员了解后得知我们很少使用同步方式实现对资源的共享。另外通过对javacore进行分析，并未发现同步造成的死锁现象。

――业务量过大，全部线程都被占用，出现队列等待现象

通过观察我们的业务量在高峰时确实很大，但由于我们配置的线程数都很高，尽管出现宕机时也没有达到配置的上线，所以这个方面可以被排除。――繁重的I/O，呼叫DB时间过长导致中间件内存耗尽

由于我们经常有新业务变更，尤其近期还有居民医保业务上线，因此I/O问题导致

xxxx股份有限公司 的因素也需要重点考察！

――读写本地I/O，发生阻塞，多线程耗尽jvm内存

这种现象很可能发生，应重点给予关注

 对WLS SERVER 宕机的几种情况的分析：

――OufOfMemory 目前xxx社保应用服务器出现宕机的时候基本都表现为这种现象，这也是中间件服务器最常见的现象。原因可能有多种，可能是平台的，多数情况下是物理内存配置过低，或jvm参数配置过低造成的。但通过对xxx社保配置参数进行分析发现参数基本合理，除了线程数和连接池配置稍大点，其它都很正常。由此分析是估计是其它原因造成的。

其它可能的原因可能是平台原因，比如jvm版本、垃圾回收方式和算法的缺陷等；也可能是应用造成的，比如业务并发量过大，内存不足造成，也可能是返回大结果集以及会话存放对象过多等原因。因此重点是找出可行的解决方案，避免出现内存溢出，减少对jvm内存的使用量。――平台bug 比如jni、jvm、os的bug等。每个weblogic版本都有对应的平台Jni，用来增加系统性能，但有时表现出不稳定的现象。Jvm和os版本对WLS server的稳定更是影响很大，通过以前的记录发现ibm和linux的应用服务器比hp出现的宕机频率更多些，因此有必要对ibm和linuxjvm做些分析和调整。

第二章

解决方法路线图

通过前面分析把解决问题的路线图定位在三方面，一个是调整现有平台jvm版本和参数，尽量达到平台的稳定性；另外一个是考虑如何减少jvm内存的使用上，尤其要解决访问DB慢以及返回大结果集这两方面，以期通过增强访问速度减少并发量，减少返回结果对内存的占用，从而使系统不发生或少发生OutOfMemory现象。另外，在意外出现宕机的情况下，通过负载均衡器的配置实现新请求直接发送给其它运行正常的服务器。

2.1 jvm的调整

采用方法：

 调整ibm应用服务器的 jvm 系统参数 kcluster等，消除内存碎片。 调整 linux应用服务器的jvm，由bea的jrockit到sun jdk。

xxxx股份有限公司 实际效果：

 Ibm服务器jvm为1.4.2，由于本版本的垃圾回收算法问题，会出现内存碎片，7月份相应调整了jvm参数，不过还是宕机很多次，没有明显效果。通过对8月份ibm服务器一次宕机javacore分析，发现在高峰阶段jvm还是会出现heap lock资源等待现象，经查ibm资料，基本上还是证实是内存碎片过多，并发申请内存太多导致系统无内存可用，最后宕机。不过8月份已经好很多了，才发现一次。这种情况目前最好方法是通过减少并发量来解决，由于应用的原因目前还无法升级jvm。 Linux服务器的jvm通过从jroick调整到sun后，在7月份就效果就很好。在8月份系统出现一次没有响应了，当时内存还是剩余很多的，现象也是OutOfMemory，但同时报sun javaException in thread “CompilerThread0” java.lang.OutOfMemoryError: requested 32760 bytes forChunkPool::allocate.Out of swap space? 经查这种现象跟在linux平台上jvm虚拟机不稳定有关，但这种现象不会经常出现。

2.2 减少jvm内存使用

想办法减少jvm内存使用量是解决问题的关键，减少应用服务器瞬时的并发量是一个好的途径，这就要保证快速的DB访问，小的结果集返回，session中少量的保存对象，同时会话保持不宜过长。

2.2.1 加快db访问速度，减少中间件并发业务量

采用方法1：通过oracle oem等工具跟踪监控大量耗I/O的语句，同时监控其它影响db服务器运行慢的进程。

实际效果：项目组调整低性能的sql后，该部分业务明显加快，没有再发现相关业务的大量全表扫描等情况。

采用方法2：对影响应收预览速度的ac40瘦身，重建并进行了分区。实际效果：根据现场反映速度有些提升。但由于对另外一个影响速度的关键表ab30无法瘦身（医保业务用），目前应收预览速度要有质的飞跃还很难。

xxxx股份有限公司

2.2.2 限制sql返回结果集

采用方法：从底层编写监控sql返回的大结果集程序，可定制记录数等参数

实际效果：目前已经抓到很多大sql，返回的结果集从几千达到10几万以上，基本消除了大结果集造成的原因，长期部署可对新程序新业务的大结果集检验有非常大的好处。

2.2.3 减少业务会话中存放的对象

采用方法：减少会话中的存放对象数，把没有必要或不需要使用的对象从会话中清除。

实际效果：这是一个备用手段，由于是改动了程序，为了生产安全考虑，暂时没有部署，在其它手段没有效果的情况下经过测试后再把它加载上去。

2.3 对本地读写的定位

通过对大量ibm java core分析，发现有读写I/O导致的堵塞。

2.4 补救措施

方法：在应用服务器上部署一个test.html静态页面，同时在负载均衡器上配置对这个静态页面的定时访问。

结果：通过8月份业务的实际运行考验确实起到了作用，7月份当一台服务器没有响应的时候马上就有业务人员反映，8月份却没有，同时我们也发现了的确新的请求就不再发给问题服务器，重新启动后新请求一点一点的加载上来，改善是很有效果的。

第三章、解决结果与进一步建议

3.1 解决结果

通过两个月周期的现场分析、调整，目前应用服务器系统稳定性已经明显提高了。尽管

xxxx股份有限公司 月底个别高峰的时候还会出现系统没有响应情况，但通过其它手段弥补已经不会影响业务的运行。

分析导致系统宕机因素是多方面的，包括java平台的原因，程序大结果集的原因，表数据量大/sql程序不够优化的原因，阵列I/O性能的原因、并发大业务的等原因。这些原因往往交织在一起，呈现出各种系统宕机状况。但最终只要我们提高sql的运行速度，降低jvm的内存使用量，把握好大的结果集和大的业务对象使用，尽管jvm本身有不稳定的情况，也不会或很少出现jvm宕机现象的。

3.2 进一步建议

 优化或升级现有阵列

目前整体系统的瓶颈在I/O上，希望考虑阵列升级计划。 对目前业务数据和程序做一个周期瘦身和优化方案

从系统整体性能分析看，不良的I/O状况，越来越多的上亿记录的表导致大量对数据库操作业务缓慢，使中间件服务器并发量瞬时增加，中间件服务器的负载量加重，也成为中间件的宕机的一个主要原因。

 优化本地I/O读写，将日志调试信息去掉。

 对新业务继续监控大结果集（目前部署在11、12上）。

 对新业务继续要做及时监控，抓大sql（耗I/O量大，运行次数多，阻塞其它业务）。

xxxx股份有限公司

第二篇：性能测试总结之内存泄露和内存溢出

性能测试总结之内存泄露和内存溢出

主要从以下几部分来说明，关于内存和内存泄露、溢出的概念，区分内存泄露和内存溢出;内存的区域划分，了解GC回收机制;重点关注如何去监控和发现内存问题;此外分析出问题还要如何解决内存问题。

下面就开始本篇的内容：

第一部分 概念

众所周知，java中的内存java虚拟机自己去管理的，他不想C++需要自己去释放。笼统地去 讲，java的内存分配分为两个部分，一个是数据堆，一个是栈。程序在运行的时候一般分配数据堆，把局部的临时的变量都放进去，生命周期和进程有关系。但 是如果程序员声明了static的变量，就直接在栈中运行的，进程销毁了，不一定会销毁static变量。

另外为了保证java内存不会溢出，java中有垃圾回收机制。System.gc()即垃圾收集机制是指jvm用于释放那些不再使用的对象所占用的内存。java语言并不要求jvm有gc，也没有规定gc如何工作。垃圾收集的目的在于清除不再使用的对象。gc通过确定对象是否被活动对象引用来确定是否收集该对象。

而其中，内存溢出就是你要求分配的java虚拟机内存超出了系统能给你的，系统不能满足需求，于是产生溢出。

内存泄漏是指你向系统申请分配内存进行使用(new)，可是使用完了以后却不归还(delete)，结果你申请到的那块内存你自己也不能再访问，该块已分配出来的内存也无法再使用，随着服务器内存的不断消耗，而无法使用的内存越来越 多，系统也不能再次将它分配给需要的程序，产生泄露。一直下去，程序也逐渐无内存使用，就会溢出。

第二部分 原理

JAVA垃圾回收及对内存区划分

在Java虚拟机规范中，提及了如下几种类型的内存空间：

◇ 栈内存(Stack)：每个线程私有的。

◇ 堆内存(Heap)：所有线程公用的。

◇ 方法区(Method Area)：有点像以前常说的“进程代码段”，这里面存放了每个加载类的反射信息、类函数的代码、编译时常量等信息。

◇ 原生方法栈(Native Method Stack)：主要用于JNI中的原生代码，平时很少涉及。

而Java的使用的是堆内存，java堆是一个运行时数据区，类的实例(对象)从中分配空间。Java虚拟机(JVM)的堆中储存着正在运行的应用程序所建立的所有对象，“垃圾回收”也是主要是和堆内存(Heap)有关。

垃圾回收的概念就是JAVA虚拟机(JVM)回收那些不再被引用的对象内存的过程。一般我们认为正在被引用的对象状态为“alive”，而没有 被应用或者取不到引用属性的对象状态为“dead”。垃圾回收是一个释放处于”dead”状态的对象的内存的过程。而垃圾回收的规则和算法被动态的作用于 应用运行当中，自动回收。

JVM的垃圾回收器采用的是一种分代(generational)回收策略，用较高的频率对年轻的对象(young generation)进行扫描和回收，这种叫做minor collection，而对老对象(old generation)的检查回收频率要低很多，称为major collection。这样就不需要每次GC都将内存中所有对象都检查一遍，这种策略有利于实时观察和回收。

(Sun JVM 1.3 有两种最基本的内存收集方式：一种称为copying或scavenge，将所有仍然生存的对象搬到另外一块内存后，整块内存就可回收。这种方法有效率，但需要有一定的空闲内存，拷贝也有开销。这种方法用于minor collection。另外一种称为mark-compact，将活着的对象标记出来，然后搬迁到一起连成大块的内存，其他内存就可以回收了。这种方法不 需要占用额外的空间，但速度相对慢一些。这种方法用于major collection.)

一些对象被创建出来只是拥有短暂的生命周期，比如 iterators 和本地变量。

另外一些对象被创建是拥有很长的生命周期，比如 高持久化对象等。

垃圾回收器的分代策略是把内存区划分为几个代，然后为每个代分配一到多个内存区块。当其中一个代用完了分配给他的内存后，JVM会在分配的内存 区内执行一个局部的GC(也可以叫minor collection)操作，为了回收处于“dead”状态的对象所占用的内存。局部GC通常要不Full GC要快很多。

JVM定义了两个代，年轻代(yong generation)(有时称为“nursery”托儿所)和老年代(old generation)。年轻代包括 “Eden space(伊甸园)”和两个“survivor spaces”。虚拟内存初始化的时候会把所有对象都分配到 Eden space，并且大部分对象也会在该区域被释放。当进行 minor GC的时候，VM会把剩下的没有释放的对象从Eden space移动到其中一个survivor spaces当中。此外，VM也会把那些长期存活在survivor spaces 里的对象移动到 老生代的“tenured” space中。当 tenured generation 被填满后，就会产生Full GC，Full GC会相对比较慢因为回收的内容包括了所有的 live状态的对象。pemanet generation这个代包括了所有java虚拟机自身使用的相对比较稳定的数据对象，比如类和对象方法等。

关于代的划分，可以从下图中获得一个概况：

如果垃圾回收器影响了系统的性能，或者成为系统的瓶颈，你可以通过自定义各个代的大小来优化它的性能。使用JConsole，可以方便的查看到当前应用所配置的垃圾回收器的各个参数。想要获得更详细的参数，可以参考以下调优介绍：

Tuning Garbage collection with the 5.0 HotSpot VM

http://java.sun.com/docs/hotspot/gc/index.html

最后，总结一下各区内存：

Eden Space(heap)： 内存最初从这个线程池分配给大部分对象。

Survivor Space(heap)：用于保存在eden space内存池中经过垃圾回收后没有被回收的对象。

Tenured Generation(heap)：用于保持已经在 survivor space内存池中存在了一段时间的对象。

Permanent Generation(non-heap): 保存虚拟机自己的静态(refective)数据，例如类(class)和方法(method)对象。Java虚拟机共享这些类数据。这个区域被分割为只读的和只写的，Code Cache(non-heap):HotSpot Java虚拟机包括一个用于编译和保存本地代码(native code)的内存，叫做“代码缓存区”(code cache)

第三部分 监控(工具发现问题)

谈到内存监控工具，JConsole是必须要介绍的，它是一个用JAVA写的GUI程序，用来监控 VM，并可监控远程的VM，易用且功能强大。具体可监控JAVA内存、JAVA CPU使用率、线程执行情况、加载类概况等，Jconsole需要在JVM参数中配置端口才能使用。

由于是GUI程序，界面可视化，这里就不做详细介绍，具体帮助支持文档请参阅性能测试JConsole使用方法总结：

http://

http://Java.sun.com/javase/6/docs/technotes/tools/share/jconsole.html

在实际测试某一个项目时，内存出现泄露现象。起初在性能测试的1个小时中，并不明显，而在稳定性测试的时候才发现，应用的HSF调用在经过几个 小时运行后，就出现性能明显下降的情况。在服务日志中报大量HSF超时，但所调用系统没有任何超时日志，并且压力应用的load都很低。经过查看日志后，认为应用可能存在内存泄漏。通过jconsole 以及 jmap 工具进行分析发现，确实存在内存泄漏问题，其中PS Old Gen最终达到占用 100%的占用。如图所示：

从上图可以看到，虽然每次Full GC，JVM内存会有部分回收，但回收并不彻底，不可回收的内存对象会越来越多，这样便会出现以上的一个趋势。在Full GC无法回收的对象越来越多时，最终已使用内存达到系统分配的内存最大值，系统最后无内存可分配，最终down机。

第四部分 分析

经过开发和架构师对应用的分析，查看此时内存队列，看哪个对象占用数据最多，再利用jmap命令，对线程数据分析，如下所示：

num #instances #bytes class name

1: 9248056 665860032 com.taobao.matrix.mc.domain.**

2: 9248031 295936992 com.taobao.matrix.**

3: 9248068 147969088 java.util.**

4: 1542111 37010664 java.util.Date

前三个instances不断增加，指代的是同一个代码逻辑，异步分发的问题，堵塞消息，回收多次都无法回收成功。导致内存溢出。

此外，对应用的性能单独做了压测，他的性能只能支撑到一半左右，故发送消息的TPS，应用肯定无法处理过来，导致消息堆积，而JAVA垃圾回收期认为这些都是有用的对象，导致内存堆积，直至系统崩溃。

调优方法

由于具体调优方法涉及到应用的配置信息，故在此暂不列出，可以参考性能测试小组发布的《性能测试调优宝典》

第四部分 总结

内存溢出主要是由于代码编写时对某些方法、类应用不合理，或者没有预估到临时对象会占用很大内存量，或者把过多的数据放入JVM缓存，或者性能 压力大导致消息堆积而占用内存，以至于在性能测试时，生成庞大数量的临时对象，GC时没有做出有效回收甚至根本就不能回收，造成内存空间不足，内存溢出。

如果编码之前，对内存使用量进行预估，对放在内存中的数据进行评估，保证有用的信息尽快释放，无用的信息能够被GC回收，这样在一定程度上是可以避免内存溢出问题的。

第三篇：性能测试总结之内存泄露和内存溢出

性能测试总结之内存泄露和内存溢出

2009-12-10 作者：yunshuai 来源：Taobao QA Team

刚刚做完了一个项目的性能测试，“有幸”也遇到了内存泄露的案例，所以在此和大家分享一下。

主要从以下几部分来说明，关于内存和内存泄露、溢出的概念，区分内存泄露和内存溢出；内存的区域划分，了解GC回收机制；重点关注如何去监控内存问题；此外分析出问题还要如何解决内存问题。下面就开始本篇的内容： 第一部分 概念

众所周知，java中的内存java虚拟机自己去管理的，他不想C++需要自己去释放。笼统地去讲，java的内存分配分为两个部分，一个是数据堆，一个是序在运行的时候一般分配数据堆，把局部的临时的变量都放进去，生命周期和进程有关系。但是如果程序员声明了static的变量，就直接在栈中运行的，进了，不一定会销毁static变量。

另外为了保证java内存不会溢出，java中有垃圾回收机制。System.gc()即垃圾收集机制是指jvm用于释放那些不再使用的对象所占用的内存。java语言求jvm有gc，也没有规定gc如何工作。垃圾收集的目的在于清除不再使用的对象。gc通过确定对象是否被活动对象引用来确定是否收集该对象。而其中，内存溢出就是你要求分配的java虚拟机内存超出了系统能给你的，系统不能满足需求，于是产生溢出。

内存泄漏是指你向系统申请分配内存进行使用(new)，可是使用完了以后却不归还(delete)，结果你申请到的那块内存你自己也不能再访问,该块已分配出存也无法再使用，随着服务器内存的不断消耗，而无法使用的内存越来越多，系统也不能再次将它分配给需要的程序，产生泄露。一直下去，程序也逐渐使用，就会溢出。第二部分 原理

JAVA垃圾回收及对内存区划分

在Java虚拟机规范中，提及了如下几种类型的内存空间： ◇ 栈内存（Stack）：每个线程私有的。◇ 堆内存（Heap）：所有线程公用的。

◇ 方法区（Method Area）：有点像以前常说的“进程代码段”，这里面存放了每个加载类的反射信息、类函数的代码、编译时常量等信息。◇ 原生方法栈（Native Method Stack）：主要用于JNI中的原生代码，平时很少涉及。

而Java的使用的是堆内存，java堆是一个运行时数据区，类的实例(对象)从中分配空间。Java虚拟机(JVM)的堆中储存着正在运行的应用程序所建立的象，“垃圾回收”也是主要是和堆内存（Heap）有关。

垃圾回收的概念就是JAVA虚拟机（JVM）回收那些不再被引用的对象内存的过程。一般我们认为正在被引用的对象状态为“alive”,而没有被应用或者取用属性的对象状态为“dead”。垃圾回收是一个释放处于”dead”状态的对象的内存的过程。而垃圾回收的规则和算法被动态的作用于应用运行当中，自动回JVM的垃圾回收器采用的是一种分代（generational）回收策略，用较高的频率对年轻的对象(young generation)进行扫描和回收，这种叫做minor collec对老对象(old generation)的检查回收频率要低很多，称为major collection。这样就不需要每次GC都将内存中所有对象都检查一遍，这种策略有利于实时观收。

（Sun JVM 1.3 有两种最基本的内存收集方式：一种称为copying或scavenge，将所有仍然生存的对象搬到另外一块内存后，整块内存就可回收。这种效率，但需要有一定的空闲内存，拷贝也有开销。这种方法用于minor collection。另外一种称为mark-compact，将活着的对象标记出来，然后搬迁到一起块的内存，其他内存就可以回收了。这种方法不需要占用额外的空间，但速度相对慢一些。这种方法用于major collection.）一些对象被创建出来只是拥有短暂的生命周期，比如 iterators 和本地变量。另外一些对象被创建是拥有很长的生命周期，比如 高持久化对象等。

垃圾回收器的分代策略是把内存区划分为几个代，然后为每个代分配一到多个内存区块。当其中一个代用完了分配给他的内存后，JVM会在分配的内存行一个局部的GC（也可以叫minor collection）操作，为了回收处于“dead”状态的对象所占用的内存。局部GC通常要不Full GC要快很多。

JVM定义了两个代，年轻代（yong generation）（有时称为“nursery”托儿所）和老年代(old generation)。年轻代包括 “Eden space（伊甸园）”和两个“survivor虚拟内存初始化的时候会把所有对象都分配到 Eden space，并且大部分对象也会在该区域被释放。当进行 minor GC的时候，VM会把剩下的没有释放的Eden space移动到其中一个survivor spaces当中。此外，VM也会把那些长期存活在survivor spaces 里的对象移动到 老生代的“tenured” space中。当 tenured g被填满后，就会产生Full GC，Full GC会相对比较慢因为回收的内容包括了所有的 live状态的对象。pemanet generation这个代包括了所有java虚拟机自身相对比较稳定的数据对象，比如类和对象方法等。关于代的划分，可以从下图中获得一个概况：

如果垃圾回收器影响了系统的性能，或者成为系统的瓶颈，你可以通过自定义各个代的大小来优化它的性能。使用JConsole，可以方便的查看到当前应置的垃圾回收器的各个参数。想要获得更详细的参数，可以参考以下调优介绍： Tuning Garbage collection with the 5.0 HotSpot VM http://java.sun.com/docs/hotspot/gc/index.html 最后，总结一下各区内存：

Eden Space(heap)： 内存最初从这个线程池分配给大部分对象。

Survivor Space(heap)：用于保存在eden space内存池中经过垃圾回收后没有被回收的对象。Tenured Generation(heap)：用于保持已经在 survivor space内存池中存在了一段时间的对象。

Permanent Generation(non-heap): 保存虚拟机自己的静态(refective)数据，例如类（class）和方法（method）对象。Java虚拟机共享这些类数据。这个区割为只读的和只写的，Code Cache(non-heap):HotSpot Java虚拟机包括一个用于编译和保存本地代码（native code）的内存，叫做“代码缓存区”（code cache）第三部分 监控（工具发现问题）

谈到内存监控工具，JConsole是必须要介绍的，它是一个用JAVA写的GUI程序，用来监控VM，并可监控远程的VM，易用且功能强大。具体可监控内存、JAVA CPU使用率、线程执行情况、加载类概况等，Jconsole需要在JVM参数中配置端口才能使用。由于是GUI程序，界面可视化，这里就不做详细介绍，具体帮助支持文档请参阅性能测试JConsole使用方法总结：

http:// http://Java.sun.com/javase/6/docs/technotes/tools/share/jconsole.html

在实际测试某一个项目时，内存出现泄露现象。起初在性能测试的1个小时中，并不明显，而在稳定性测试的时候才发现，应用的HSF调用在经过几个行后，就出现性能明显下降的情况。在服务日志中报大量HSF超时，但所调用系统没有任何超时日志，并且压力应用的load都很低。经过查看日志后，认可能存在内存泄漏。通过jconsole 以及 jmap 工具进行分析发现，确实存在内存泄漏问题，其中PS Old Gen最终达到占用 100%的占用。如图所示：

从上图可以看到，虽然每次Full GC，JVM内存会有部分回收，但回收并不彻底，不可回收的内存对象会越来越多，这样便会出现以上的一个趋势。在无法回收的对象越来越多时，最终已使用内存达到系统分配的内存最大值，系统最后无内存可分配，最终down机。第四部分 分析

经过开发和架构师对应用的分析，查看此时内存队列，看哪个对象占用数据最多，再利用jmap命令，对线程数据分析，如下所示： num #instances #bytes class name ———————————————-1: 9248056 665860032 com.taobao.matrix.mc.domain.** 2: 9248031 295936992 com.taobao.matrix.** 3: 9248068 147969088 java.util.** 4: 1542111 37010664 java.util.Date 前三个instances不断增加，指代的是同一个代码逻辑，异步分发的问题，堵塞消息，回收多次都无法回收成功。导致内存溢出。此外，对应用的性能单独做了压测，他的性能只能支撑到一半左右，故发送消息的TPS，应用肯定无法处理过来，导致消息堆积，而JAVA垃圾回收期些都是有用的对象，导致内存堆积，直至系统崩溃。

调优方法

由于具体调优方法涉及到应用的配置信息，故在此暂不列出，可以参考性能测试小组发布的《性能测试调优宝典》 第四部分 总结

内存溢出主要是由于代码编写时对某些方法、类应用不合理，或者没有预估到临时对象会占用很大内存量，或者把过多的数据放入JVM缓存，或者性大导致消息堆积而占用内存，以至于在性能测试时，生成庞大数量的临时对象，GC时没有做出有效回收甚至根本就不能回收，造成内存空间不足，内存如果编码之前，对内存使用量进行预估，对放在内存中的数据进行评估，保证有用的信息尽快释放，无用的信息能够被GC回收，这样在一定程度上是免内存溢出问题的。

第四篇：Linux系统内存使用的体会及命令解释

Linux系统内存使用的体会及命令解释

发布时间：2006.09.26 04:45来源：chinaunix.net作者：nonameboy

Linux的内存管理，实际上跟windows的内存管理有很相像的地方，都是用虚拟内存这个的概念，说到这里不得不骂MS，为什么在很多时候还有很大的物理内存的时候，却还是用到了pagefile.所以才经常要跟一帮人吵着说Pagefile的大小，以及如何分配这个问题，在Linux大家就不用再吵什么swap大小的问题，我个人认为，swap设个512M已经足够了，如果你问说512M的SWAP不够用怎么办？只能说大哥你还是加内存吧，要不就检查你的应用，是不是真的出现了memory leak.夜也深了，就不再说废话了。

在Linux下查看内存我们一般用command free；

[root@nonamelinux ]# free total used free shared buffers cached； Mem: 386024 377116 8908 0 21280 155468；

-/+ buffers/cache: 200368 185656；

Swap: 393552 0 393552；

下面是对这些数值的解释：

total:总计物理内存的大小。

used:已使用多大。

free:可用有多少。

Shared:多个进程共享的内存总额。

Buffers/cached:磁盘缓存的大小。

第三行(-/+ buffers/cached):

used:已使用多大。

free:可用有多少。

第四行就不多解释了。

区别：第二行(mem)的used/free与第三行(-/+ buffers/cache)used/free的区别。这两个的区别在于使用的角度来看，第一行是从OS的角度来看，因为对于OS，buffers/cached 都是属于被使用，所以他的可用内存是8908KB,已用内存是377116KB,其中包括，内核（OS）使用+Application(X,oracle,etc)使用的+buffers+cached.第三行所指的是从应用程序角度来看，对于应用程序来说，buffers/cached 是等于可用的，因为buffer/cached是为了提高文件读取的性能，当应用程序需在用到内存的时候，buffer/cached会很快地被回收。

所以从应用程序的角度来说，可用内存=系统free memory+buffers+cached。如上例：

185656=8908+21280+155468 接下来解释什么时候内存会被交换，以及按什么方交换。当可用内存少于额定值的时候，就会开会进行交换。如何看额定值（RHEL4.0）：

#cat /proc/meminfo

交换将通过三个途径来减少系统中使用的物理页面的个数：

1.减少缓冲与页面cache的大小，2.将系统V类型的内存页面交换出去，3.换出或者丢弃页面。(Application 占用的内存页，也就是物理内存不足）。事实上，少量地使用swap是不是影响到系统性能的。

下面是buffers与cached的区别。

buffers是指用来给块设备做的缓冲大小，他只记录文件系统的metadata以及 tracking in-flight pages.cached是用来给文件做缓冲。那就是说：buffers是用来存储，目录里面有什么内容，权限等等。而cached直接用来记忆我们打开的文件，如果你想知道他是不是真的生效，你可以试一下，先后执行两次命令#man X ,你就可以明显的感觉到第二次的开打的速度快很多。

实验：在一台没有什么应用的机器上做会看得比较明显。记得实验只能做一次，如果想多做请换一个文件名。

#free #man X #free #man X #free

你可以先后比较一下free后显示buffers的大小。另一个实验：

#free #ls /dev #free

你比较一下两个的大小，当然这个buffers随时都在增加，但你有ls过的话，增加的速度会变得快，这个就是buffers/chached的区别。

第五篇：校园监控系统整体解决

校园监控系统整体解决

设 计 方 案

2011年1月22日

一、现状分析

现在各地市的学校都普遍存在着校园面积大、场地分散，学生众多，学校大门口人流混乱，而且有的学校大门临街建设，很容易出现交通事故，也有部分社会不良青年聚集学校门口滋事，校园周边的环境复杂等问题。近年来校园暴力事件和突发事故的增加，传统的人力巡查已不能满足校园安全管理的需求，越来越多的学校开始考虑通过校园网络视频监控系统的实施来建设平安校园。

二、实际需求

随着学校的信息化建设不断深入，各学校都加快了信息网络平台的建设;学校正逐步转向利用网络和计算机集中处理管理、服务等重要环节的大量数据。另外，随着应用的深入，很多校园安全提出了越来越高的要求，纷纷建立校区的网络视频监控系统，为整个学校的工作、安全防卫提供了一套实时视频监控，事件视频取证的平台工具。

数字视频、音频以其直观性、易于存储、检索和共享，是学校可视信息管理系统的重要组成部分。IP视频监控系统是基于网络平台的有关安防、管理的音视频数据的管理系统，它是传统视频监控系统在功能上不断进步完善的产物，在平台结构和管理、视频资料安全方面功能强大，摆脱了传统模拟视频监控模式的大量弊端，是未来视频监控的发展方向。IVSPNET 网络视频监控管理平台就是一个基于网络平台，以多级联网管理支持分布式应用的综合性网络视频监控管理系统。特别适合学校的局部自治，中心掌控全局的多级联网应用管理平台软件。

三、系统概述

IVSPNET 网络视频监控管理平台是一个以多级联网管理并支持分布式应用的综合性网络视频监控管理系统。特别适合局部自治，中心掌控全局的多级联网应用。它具有客户端与服务器两部分，服务器又包括核心服务器、设备代理/消息服务器、流媒体服务器、二级转发服务器。功能有

集中监控与数字矩阵、回放下载、系统配置、电子地图、报警采集与联动等功能。同时，它具有兼容多厂家品牌视频设备的能力，目前可以兼容海康全系列(包括最新的9000系列)、大华、恒亿、朗驰相关的DVR、DVS、IPCAM。还具有良好的联动功能，不同的设备可任意联动，使系统能够协同工作，对异常情况能够及时有效地处理。其主要具有以下特性：

3.1.1设计思想的先进性

本系统一方面提升技防的科技含量，实现学校安全保卫手段的现代化。通过本系统，实现校园安全保卫由劳动密集性向知识密集型的转化，提升安全系数和防范效率；

另一方面是深化监控中心职能，实现校园内控监管的现代化。将监控中心由原先单纯的监控和威慑转变到内控管理、业务监督等多重功能上来，将技术领先的优势扩大到内控监管上来，有效整合和合理利用现有资源，使之成为学校的信息中心、控制中心、管理中心、从而大大提高学校整体工作的集约化水平和工作效率。

3.1.2系统平台的统一性和功能的完备性

系统应为管理者和使用者提供统一的操作平台，让使用更加方便，直观显示操作的结果。学校内共有图像监视、防盗报警、灯光电源管理、空调控制等系统，从管理和使用角度考虑，应在一个统一的平台上面来控制，而不需控制多种设备而启动多个控制系统；

从系统的功能模块构成上看，包含电子地图、语音对讲、语音广播、DVR远程管理、远程监看图像、远程控制照明等设备、系统日志……等等，应能够除监控设备以外能够控制监控周边设备。

3.1.3系统运行的稳定性和可靠性

多级的系统架构，保证了系统的稳定运行；

具有设计独到的视频流及数据流管理功能，保证网络连接通畅；

系统具有自诊断和调节功能，保证系统运行于正常状态；

同时，系统应得到学校应用的考验。系统设备的平均无故障工作时间MTBF>10000小时。

3.1.4前端设备的兼容性

系统兼容性和开放性：主要体现在软件可与前端的各种不同生产厂家的设备（DVR /DVS/IP CAMERA）兼容。

软件兼容市场上主流板卡（海康威视M/H/HC卡、恒亿6000/4000卡等），视频解码软件兼容海康威视MD卡、7000卡、8000卡等、在建设监控中心时，只要是上述板卡，仅需换上本软件，不需更换硬件即可；

本软件同时兼容海康威视、浙江大华、武汉恒忆等市场上销售的大部分具有网络功能的嵌入式DVR。

兼容性的意义：对前期改造项目而言，连锁店（学校）可避免重复建设的投资，节约成本。系统集成商的解决方案灵活，不会受制于人；对后续建设网点来说，连锁店（学校）不会被某一家设备供应商牵制，可选择市场上性价比最好的产品。

3.1.5系统的扩展性

为了适应未来系统扩展的要求，系统在满足现有功能的基础上预留足够的设备容纳性以便系统扩充之用。系统中控制部件（软、硬件）采用集中式结构、嵌入式模块等技术措施，方便灵活的进行扩充，充分保证系统在将来的适应性；

灵活的组网方式，方便被监控点的增加；

多级架构可以把连锁店（学校）组成更大的视频监控系统，形成大规模的监控网络，连锁总店（学校）监控中心能管理和监控分学校的运行，具有较强的适应性和可扩充性。

3.1.6易用性和易维护

系统硬件平台为标准2U/4U服务器，硬件连接采用标准化接口，高度工程化，便于施工、安装、调试；

系统的软件操作简便，能应用于Windows2000/NT/XP/2003等操作系统，方便连锁店（学校）人员的使用和系统的日常维护；

软件使用界面良好，用户安装相应软件后就可进行实现监控，完全智能控制，不用单独设置；

系统可以很方便进行软件升级，保证用户投资。系统采用的软件，包括：服务器软件和客户端软件，均为客户提供升级服务。

四、系统主要功能特色及优势服务

IVSPNET 网络视频监控管理平台是基于计算机网络、图像编解码、数据通信、控制及监控技术等领域而自主开发的全数字化网络远程集中监控管理平台。此平台采用分布、多级网络互联设计，基于Intranet/Internet架构、采用客户端/服务器模式(Client/Server)与浏览器/服务器(Browser/Server)模式，通过TCP/IP协议的模块化结构设计，根据不同用户需求灵活配置和定制。

4.1.IVSPNET 网络视频监控管理平台主要特色

4.1.1集中管理

一般情况下，大型的学校需要集中管理各个分校，IVSPNET-很好地满足了这一需求，完善的权限管理机制和流媒体转播技术，可以在任何需要建立分控中心的地方设立监视工作站或监视器，系统提供按照需要为各分学校及用户灵活分配权限及可查看摄像机的能力，使监视系统完全与日常工作相符合。

4.1.2适应性强

在技术上，IVSPNET不仅可以适应复杂的网络环境，而且可以将视频图像从前端设备通过流媒体服务器，直接以组播流的形式发送给多个用户，大大降低了对网络资源的占用。监视界面不仅支持多种分割显示方式，而且可以根据需要建立多个分割显示画面（布局页），各分割显示画面之间可以手动或自动顺序切换，这样即使监视点数很多，也可通过一个工作站来快速查看所有的摄像机图像。

4.1.3网络兼容性强

视频传输是基于TCP/IP协议，可跨越网关及路由，适应不同的网络环境。此外，利用流媒体DVR，通过真正的流媒体技术，可以适应窄带传输，从而对任何有IP网络连通的任何地方都可以实现监控。

4.1.4软硬件同时解码显示

IVSPNET支持软、硬件同时对视频流进行解码显示，很好地兼容数字（显示器、背投、大屏幕）与模拟监视设备（监视器），从而非常方便地建立集中监控中心与多个分散的分控中心。实现了软硬结合，实时性、可靠性与灵活性、实用性并存。

4.1.5音视频同步

IVSPNET可以集成全双工语音通信功能，实现音视频同步监控、双向通话及语音广播功能。

4.1.6支持IE浏览

IVSPNET内部有WEB服务器，用户可以直接用IE浏览器访问设备以查看视频图像或配置设备，也可以通过IE浏览器登录系统服务器（Directory Server），以获取摄像机列表，点击其中一个即可查看视频图像或控制摄像机上、下、左、右转动。

4.1.7强大的电子地图

IVSPNET支持电子地图，可以将各摄像机、输入开关、输出开关、子电子地图位置映射在电子地图上，当点击电子地图上的图标时，该图标所对应的图像会自动弹出。支持电子地图专题标绘，直观表现现场环境，与报警接收联动等功能完美集成在一起，支持查询分类专题点，放大与缩小平移电子地图。

本功能的使用需要建立在系统配置功能配好各项数据的前提下使用。支持多级电子地图使用。

4.2.IVSPNET网络视频监控管理平台的主要功能：

IVSPNET 网络视频监控管理平台可以对学校中不同厂家的设备的各种重要信息进行综合处理，生成安防系统管理所需要的综合数据库，从而对所有全局事件进行集中管理。因此，在学校的总控制中心的管理计算机上，可以得到各个分校的有关的数据，并将关系到各个分学校正常运行、重要的报警信息汇集上来，得到统一的管理，定期输出设备运行及管理的各类报表，为集成系统设备的正常、经济运行提供可靠、完整的依据，同时将所有分学校之间需要共享的数据收集上来，存储到统一的开放式数据库当中，实现各学校之间的信息共享和集中的设备监控、报警管理和联动控制功能。

该系统监控平台由音视频监控、电子地图管理、语音及广播管理、模拟数字矩阵、报警远程联动、远程电动设备控制管理等系统组成，实现多系统统一平台的集中控制和管理。

主要功能如下：

                远程视频轮巡显示及监视功能；

红外、烟感、玻璃破碎、有毒汽体报警功能； 远程布/撤防和报警联动上传功能； 双向语音对讲及广播功能； 远程实时查看图像、实时录像； 远程录像资料检索及数据备份；

远程对前端设备进行重启、注册、注销、配置、校时功能； 远程开关量输出及灯光/空调等设备控制功能； 具有多种报警联动方式和报警控制功能；

分布式网络视频接入，集中权限控制和资源管理，多级组织结构等功能；

前端设备IP自动上传功能（动态IP）； 模拟数字矩阵视频上墙功能； 强大的电子地图功能； 日志文档分类管理和检索；

流媒体转播、二级中转及多级分控中心和不同需求内控功能； 兼容和整合其它系统，实现资源共享，达到操作简便。

4.3.IVSPNET网络视频监控管理平台优势服务；

4.3.1显示服务

 显示管理   该部分相当于一个数字视频显示矩阵。

与配置服务器配合工作，决定画面显示策略（固定、轮切、插播显示）和屏幕的分屏方式（1、4、9、16分屏方式）；  与配置服务器配合工作，决定前端的某路图像上电视墙，同时显示在屏幕上的某个位置，何时显示。

 画面显示  纯解码功能，需要硬件配置，根据解码方式可分为：

 数字显示：即利用计算机软件解码后将图像显示到显示器上。数字显示可在同一屏幕显示任意不同品牌板卡视频图像的组合。

 模拟显示：即通过硬件解码卡解码后将图像显示到监视器上。模拟显示不能兼容多品牌的视频图像。

 数字矩阵/远程控制显示服务器播放

4.3.2设备代理／消息服务

设备代理／消息服务是前端设备与客户端软件通讯各类信息的枢纽，可调出各个的学校的节点，自定订阅各个的学校所有设备的事件，并支持转发消息。支持设备各种报警，无视频信号报警，移动视频报警等，IO报警，硬盘损坏，空间不足等。

  与前端设备及客户端协调工作；显示前端设备及客户端的各种信息，便于学校监控人员查看； 动态ＩＰ功能；当前端设备没有固定IP（动态IP）时，或有静态IP，由于某种原因无法得知，便可启用动态IP功能。

4.3.3接/处警服务

 接警联动



接收远程报警信号，并做明显的弹出信息提示；

    接收远程报警信号后自动在中心录像； 根据联动策略设置控制远端报警开关输出； 在电子地图上明显提示报警点发生地点； 根据联动策略控制本地报警输出警灯闪烁。

4.3.4控制服务

 远程网络开关

 远程网络开关控制: 远程控制网络开关的打开和关闭；

4.3.5流媒体转播服务

流媒体服务器模块主要是在多级中心或分控比较多时作为减轻网络负担而用的。它主要分为两个部分：

 录像检索

当某件事件发生时，很多部门的很多人都会同时调用同一个地方的录像资料，那么录像检索缓冲模块可在第一个人检索时，把相应的录像资料保存的缓存硬盘，从第二个要检索资料的人开始，都是从检索缓存硬盘里面直接读取资料，这样大大的减缓了网络的负担

 实时视频转播服务

当多级中心或很多分控端同时监看某路视频时，假如上级中心或每一个分学校都去监看某个网点的某路视频时，对此网点的网络造成了很大的负担。通过实时视频转播模块，无论多少人同时在线看一路视频时，都由实时视频转播模块去连接前端的视频，然后分发给各个客户端，大大的减轻了网络的负担。

4.3.6 Web服务及IE插件

WEB服务器模块给网络中其他用户通过IE 浏览器访问网点视频的功能，它主要包含三个方面的内容：

 WEB电子地图：用户通过浏览器登录WEB服务模块，可进入任何一级的电子地图，点击电子地图上的摄像机图标，可直接监看此摄像机的网络视频图像；

 WEB远程监看：用户通过浏览器，可用1、4、9等分屏方式来监看远端摄像机的视频图像，且可在分屏上任意组合不同网点的不同摄像机的视频图像；

 WEB远程状态：用户通过浏览器，可监看到远程DVR的状态，包括摄像机、硬盘、CPU使用率等的状态信息，且可进入远程DVR的Web设置界面，对远程DVR进行设置。

BS视频监控系统主界面

4.3.7语音广播服务

 支持远程实时监听，某路音频可与任意一台摄像机相连, 同步录像和录音，声音与图像数据同包；  主动呼叫功能，在总控制中心可任意选择某网点进行喊话或对话，能同时对16个网点进行广播讲话；  具双向语音对讲，对讲可以通过网络（TCP/IP协议）或电话网络（PSTN）进行，网点请求对将时，相对应的摄像机的图像可同时弹出，以便值班人员可观察现场情况；      中心能通过网络回放任意一路视频及音频信号；

音质清晰回音小，在总控制中心能自由切换其它监控点和控制音量大小 广播管理； 音频转播； 简单视频会议。

五、系统结构设计

系统整体基于IVSPNET网络视频系统结构，具有扩展容易，结构更改方便的特点。系统使用分层结构，可分为二层：

接入层：各个摄像需求点实现所有摄像头视频信号的接入，将摄像头视频采集信号传送到各个监控室。传输方式可根据具体情况采用数字或模拟的方式，本层可以通过现有的DVR或者DVS对视频监控图像进行存储。使用数模相结合的方式实现。

核心层：总监控中心采用全数字监控，各个监控室通过网络链路上联到总监控中心，实现全部数字信号汇聚到总监控中心，总监控中心实现重点调用以及指挥调度。

考虑校方的发展及后期工程的需要，本方案总体结构：采用IVSPNET网络视频监控系统平台软件，来实现无限扩容要求：

各监控点通过视频电缆或光纤连接至监控中心;

各个视频服务器和总监控中心通过光纤进行TCP/IP网络互连;

实现各个监控室图像对保安总监控中心的上传和保安总控制中心对各个视频服务器数据的控制和调用;

通过IVSPNET网络视频监控系统平台软件的构建结构，以后的各个监控室(分控室的摄像机不限数量)都能接入到保安总监控中心，同时不需重复增加保安总监控中心的控制设备。

5．1系统主要技术构成

系统将以“前端摄像机+视频服务器+IVSPNET网络视频管理平台+数字网络矩阵”为核心，以IVSPNET网络视频监控系统为主，对音视频信号的传输、控制、切换、显示进行集中式控制、管理，有关领导和管理人员可通过TCP/IP网络获得相关授权并进行分级辅控、监看。

系统设计以网络数字化为主，有非常好的扩充性和对设备的兼容性，并提供相关接口，便于系统未来的扩充、升级。

六、总结

基于“IVSPNET集成管理系统平台”的系统解决方案不仅保证了银行视频联网监控系统对网络资源的合理应用，更保证了系统运行的可行性及可靠性，并且有效的控制了系统的建设成本、网络建设成本及系统维护成本，使学校视频联网监控系统真正走向成熟。