第一篇：系統(tǒng)應(yīng)用服務(wù)器內(nèi)存溢出解決報告

XXX系統(tǒng)應(yīng)用服務(wù)器內(nèi)存溢出解決報告

xxxx股份有限公司

2010.9

目錄

第一章 問題現(xiàn)象與分析................................................................................2

1.1、問題現(xiàn)象.....................................................................................2 1.2、通常導(dǎo)致這種現(xiàn)象的原因..................................................................2 1.3、xxx社保宕機(jī)現(xiàn)象對比分析...............................................................3 第二章

解決方法路線圖..............................................................................4

2.1 jvm的調(diào)整...................................................................................4 2.2 減少jvm內(nèi)存使用..........................................................................5 2.2.1 加快db訪問速度，減少中間件并發(fā)業(yè)務(wù)量.......................................5 2.2.2 限制sql返回結(jié)果集..................................................................6 2.2.3 減少業(yè)務(wù)會話中存放的對象.........................................................6 2.3 補(bǔ)救措施......................................................................................6 第三章、解決結(jié)果與進(jìn)一步建議......................................................................6

3.1 解決結(jié)果......................................................................................6 3.2 進(jìn)一步建議...................................................................................7

第一章 問題現(xiàn)象與分析

1.1、問題現(xiàn)象

XXX應(yīng)用服務(wù)器經(jīng)常有內(nèi)存溢出、系統(tǒng)沒有響應(yīng)的現(xiàn)象，尤其在每月的月末最為明顯。目前的應(yīng)用服務(wù)器有三種類型，其中ibm和linux應(yīng)用服務(wù)器報告頻繁出現(xiàn)內(nèi)存溢出或沒有響應(yīng)的現(xiàn)象，hp unix應(yīng)用服務(wù)器相穩(wěn)定。在出現(xiàn)問題期間Weblogic無法響應(yīng)任何客戶端請求，大量請求加載到了這臺沒有響應(yīng)的Server上，最后只有殺掉并重啟這臺應(yīng)用服務(wù)器。

1.2、通常導(dǎo)致這種現(xiàn)象的原因

WLS Server 沒響應(yīng)可能的幾種原因：

xxxx股份有限公司

1、繁重的I/O，呼叫DB時間過長導(dǎo)致中間件內(nèi)存耗盡，server沒有響應(yīng)。

2、程序死循環(huán)，loop－backs，這種情況cpu很忙，系統(tǒng)沒有響應(yīng)。

3、連接到外部server，沒響應(yīng)，由于網(wǎng)絡(luò)等原因 4、2個以上的執(zhí)行者同步死鎖

5、業(yè)務(wù)量過大，全部線程都被占用，出現(xiàn)隊列等待現(xiàn)象

6、讀寫本地I/O，發(fā)生阻塞

WLS Server 宕機(jī)的原因：

? ? ? ? OutOfMemory JNI程序 jvm的bug os的bug 1.3、xxx社保宕機(jī)現(xiàn)象對比分析

? 應(yīng)用服務(wù)器沒有響應(yīng)分析

通過初步判斷，對于xxx應(yīng)用服務(wù)器沒有響應(yīng)的情況可以做如下排出法解決： ――程序死循環(huán)

這種情況會導(dǎo)致cpu非常繁忙，而通過目前觀察，每次系統(tǒng)沒響應(yīng)的時候，cpu沒有一直100%忙，另外，對出現(xiàn)問題時的java core分析沒有發(fā)現(xiàn)這類線程，因此可以基本排除這種可能。

――連接到外部server，沒響應(yīng)，由于網(wǎng)絡(luò)等原因

目前我們的業(yè)務(wù)基本都是直接通過中間件訪問數(shù)據(jù)，沒有通過應(yīng)用服務(wù)器間調(diào)用或多數(shù)據(jù)庫調(diào)用的，基本排除這種可能。――2個以上的執(zhí)行者同步死鎖

這種情況有可能，但比較難找，一般都是業(yè)務(wù)高峰的時候才有可能出現(xiàn)，跟應(yīng)用人員了解后得知我們很少使用同步方式實現(xiàn)對資源的共享。另外通過對javacore進(jìn)行分析，并未發(fā)現(xiàn)同步造成的死鎖現(xiàn)象。

――業(yè)務(wù)量過大，全部線程都被占用，出現(xiàn)隊列等待現(xiàn)象

通過觀察我們的業(yè)務(wù)量在高峰時確實很大，但由于我們配置的線程數(shù)都很高，盡管出現(xiàn)宕機(jī)時也沒有達(dá)到配置的上線，所以這個方面可以被排除。――繁重的I/O，呼叫DB時間過長導(dǎo)致中間件內(nèi)存耗盡

由于我們經(jīng)常有新業(yè)務(wù)變更，尤其近期還有居民醫(yī)保業(yè)務(wù)上線，因此I/O問題導(dǎo)致

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

――讀寫本地I/O，發(fā)生阻塞，多線程耗盡jvm內(nèi)存

這種現(xiàn)象很可能發(fā)生，應(yīng)重點給予關(guān)注

? 對WLS SERVER 宕機(jī)的幾種情況的分析：

――OufOfMemory 目前xxx社保應(yīng)用服務(wù)器出現(xiàn)宕機(jī)的時候基本都表現(xiàn)為這種現(xiàn)象，這也是中間件服務(wù)器最常見的現(xiàn)象。原因可能有多種，可能是平臺的，多數(shù)情況下是物理內(nèi)存配置過低，或jvm參數(shù)配置過低造成的。但通過對xxx社保配置參數(shù)進(jìn)行分析發(fā)現(xiàn)參數(shù)基本合理，除了線程數(shù)和連接池配置稍大點，其它都很正常。由此分析是估計是其它原因造成的。

其它可能的原因可能是平臺原因，比如jvm版本、垃圾回收方式和算法的缺陷等；也可能是應(yīng)用造成的，比如業(yè)務(wù)并發(fā)量過大，內(nèi)存不足造成，也可能是返回大結(jié)果集以及會話存放對象過多等原因。因此重點是找出可行的解決方案，避免出現(xiàn)內(nèi)存溢出，減少對jvm內(nèi)存的使用量。――平臺bug 比如jni、jvm、os的bug等。每個weblogic版本都有對應(yīng)的平臺Jni，用來增加系統(tǒng)性能，但有時表現(xiàn)出不穩(wěn)定的現(xiàn)象。Jvm和os版本對WLS server的穩(wěn)定更是影響很大，通過以前的記錄發(fā)現(xiàn)ibm和linux的應(yīng)用服務(wù)器比hp出現(xiàn)的宕機(jī)頻率更多些，因此有必要對ibm和linuxjvm做些分析和調(diào)整。

第二章

解決方法路線圖

通過前面分析把解決問題的路線圖定位在三方面，一個是調(diào)整現(xiàn)有平臺jvm版本和參數(shù)，盡量達(dá)到平臺的穩(wěn)定性；另外一個是考慮如何減少jvm內(nèi)存的使用上，尤其要解決訪問DB慢以及返回大結(jié)果集這兩方面，以期通過增強(qiáng)訪問速度減少并發(fā)量，減少返回結(jié)果對內(nèi)存的占用，從而使系統(tǒng)不發(fā)生或少發(fā)生OutOfMemory現(xiàn)象。另外，在意外出現(xiàn)宕機(jī)的情況下，通過負(fù)載均衡器的配置實現(xiàn)新請求直接發(fā)送給其它運行正常的服務(wù)器。

2.1 jvm的調(diào)整

采用方法：

? 調(diào)整ibm應(yīng)用服務(wù)器的 jvm 系統(tǒng)參數(shù) kcluster等，消除內(nèi)存碎片。? 調(diào)整 linux應(yīng)用服務(wù)器的jvm，由bea的jrockit到sun jdk。

xxxx股份有限公司 實際效果：

? Ibm服務(wù)器jvm為1.4.2，由于本版本的垃圾回收算法問題，會出現(xiàn)內(nèi)存碎片，7月份相應(yīng)調(diào)整了jvm參數(shù)，不過還是宕機(jī)很多次，沒有明顯效果。通過對8月份ibm服務(wù)器一次宕機(jī)javacore分析，發(fā)現(xiàn)在高峰階段jvm還是會出現(xiàn)heap lock資源等待現(xiàn)象，經(jīng)查ibm資料，基本上還是證實是內(nèi)存碎片過多，并發(fā)申請內(nèi)存太多導(dǎo)致系統(tǒng)無內(nèi)存可用，最后宕機(jī)。不過8月份已經(jīng)好很多了，才發(fā)現(xiàn)一次。這種情況目前最好方法是通過減少并發(fā)量來解決，由于應(yīng)用的原因目前還無法升級jvm。? Linux服務(wù)器的jvm通過從jroick調(diào)整到sun后，在7月份就效果就很好。在8月份系統(tǒng)出現(xiàn)一次沒有響應(yīng)了，當(dāng)時內(nèi)存還是剩余很多的，現(xiàn)象也是OutOfMemory，但同時報sun javaException in thread “CompilerThread0” java.lang.OutOfMemoryError: requested 32760 bytes forChunkPool::allocate.Out of swap space? 經(jīng)查這種現(xiàn)象跟在linux平臺上jvm虛擬機(jī)不穩(wěn)定有關(guān)，但這種現(xiàn)象不會經(jīng)常出現(xiàn)。

2.2 減少jvm內(nèi)存使用

想辦法減少jvm內(nèi)存使用量是解決問題的關(guān)鍵，減少應(yīng)用服務(wù)器瞬時的并發(fā)量是一個好的途徑，這就要保證快速的DB訪問，小的結(jié)果集返回，session中少量的保存對象，同時會話保持不宜過長。

2.2.1 加快db訪問速度，減少中間件并發(fā)業(yè)務(wù)量

采用方法1：通過oracle oem等工具跟蹤監(jiān)控大量耗I/O的語句，同時監(jiān)控其它影響db服務(wù)器運行慢的進(jìn)程。

實際效果：項目組調(diào)整低性能的sql后，該部分業(yè)務(wù)明顯加快，沒有再發(fā)現(xiàn)相關(guān)業(yè)務(wù)的大量全表掃描等情況。

采用方法2：對影響應(yīng)收預(yù)覽速度的ac40瘦身，重建并進(jìn)行了分區(qū)。實際效果：根據(jù)現(xiàn)場反映速度有些提升。但由于對另外一個影響速度的關(guān)鍵表ab30無法瘦身（醫(yī)保業(yè)務(wù)用），目前應(yīng)收預(yù)覽速度要有質(zhì)的飛躍還很難。

xxxx股份有限公司

2.2.2 限制sql返回結(jié)果集

采用方法：從底層編寫監(jiān)控sql返回的大結(jié)果集程序，可定制記錄數(shù)等參數(shù)

實際效果：目前已經(jīng)抓到很多大sql，返回的結(jié)果集從幾千達(dá)到10幾萬以上，基本消除了大結(jié)果集造成的原因，長期部署可對新程序新業(yè)務(wù)的大結(jié)果集檢驗有非常大的好處。

2.2.3 減少業(yè)務(wù)會話中存放的對象

采用方法：減少會話中的存放對象數(shù)，把沒有必要或不需要使用的對象從會話中清除。

實際效果：這是一個備用手段，由于是改動了程序，為了生產(chǎn)安全考慮，暫時沒有部署，在其它手段沒有效果的情況下經(jīng)過測試后再把它加載上去。

2.3 對本地讀寫的定位

通過對大量ibm java core分析，發(fā)現(xiàn)有讀寫I/O導(dǎo)致的堵塞。

2.4 補(bǔ)救措施

方法：在應(yīng)用服務(wù)器上部署一個test.html靜態(tài)頁面，同時在負(fù)載均衡器上配置對這個靜態(tài)頁面的定時訪問。

結(jié)果：通過8月份業(yè)務(wù)的實際運行考驗確實起到了作用，7月份當(dāng)一臺服務(wù)器沒有響應(yīng)的時候馬上就有業(yè)務(wù)人員反映，8月份卻沒有，同時我們也發(fā)現(xiàn)了的確新的請求就不再發(fā)給問題服務(wù)器，重新啟動后新請求一點一點的加載上來，改善是很有效果的。

第三章、解決結(jié)果與進(jìn)一步建議

3.1 解決結(jié)果

通過兩個月周期的現(xiàn)場分析、調(diào)整，目前應(yīng)用服務(wù)器系統(tǒng)穩(wěn)定性已經(jīng)明顯提高了。盡管

xxxx股份有限公司 月底個別高峰的時候還會出現(xiàn)系統(tǒng)沒有響應(yīng)情況，但通過其它手段彌補(bǔ)已經(jīng)不會影響業(yè)務(wù)的運行。

分析導(dǎo)致系統(tǒng)宕機(jī)因素是多方面的，包括java平臺的原因，程序大結(jié)果集的原因，表數(shù)據(jù)量大/sql程序不夠優(yōu)化的原因，陣列I/O性能的原因、并發(fā)大業(yè)務(wù)的等原因。這些原因往往交織在一起，呈現(xiàn)出各種系統(tǒng)宕機(jī)狀況。但最終只要我們提高sql的運行速度，降低jvm的內(nèi)存使用量，把握好大的結(jié)果集和大的業(yè)務(wù)對象使用，盡管jvm本身有不穩(wěn)定的情況，也不會或很少出現(xiàn)jvm宕機(jī)現(xiàn)象的。

3.2 進(jìn)一步建議

? 優(yōu)化或升級現(xiàn)有陣列

目前整體系統(tǒng)的瓶頸在I/O上，希望考慮陣列升級計劃。? 對目前業(yè)務(wù)數(shù)據(jù)和程序做一個周期瘦身和優(yōu)化方案

從系統(tǒng)整體性能分析看，不良的I/O狀況，越來越多的上億記錄的表導(dǎo)致大量對數(shù)據(jù)庫操作業(yè)務(wù)緩慢，使中間件服務(wù)器并發(fā)量瞬時增加，中間件服務(wù)器的負(fù)載量加重，也成為中間件的宕機(jī)的一個主要原因。

? 優(yōu)化本地I/O讀寫，將日志調(diào)試信息去掉。

? 對新業(yè)務(wù)繼續(xù)監(jiān)控大結(jié)果集（目前部署在11、12上）。

? 對新業(yè)務(wù)繼續(xù)要做及時監(jiān)控，抓大sql（耗I/O量大，運行次數(shù)多，阻塞其它業(yè)務(wù)）。

xxxx股份有限公司

第二篇：性能測試總結(jié)之內(nèi)存泄露和內(nèi)存溢出

性能測試總結(jié)之內(nèi)存泄露和內(nèi)存溢出

主要從以下幾部分來說明，關(guān)于內(nèi)存和內(nèi)存泄露、溢出的概念，區(qū)分內(nèi)存泄露和內(nèi)存溢出;內(nèi)存的區(qū)域劃分，了解GC回收機(jī)制;重點關(guān)注如何去監(jiān)控和發(fā)現(xiàn)內(nèi)存問題;此外分析出問題還要如何解決內(nèi)存問題。

下面就開始本篇的內(nèi)容：

第一部分 概念

眾所周知，java中的內(nèi)存java虛擬機(jī)自己去管理的，他不想C++需要自己去釋放?；\統(tǒng)地去 講，java的內(nèi)存分配分為兩個部分，一個是數(shù)據(jù)堆，一個是棧。程序在運行的時候一般分配數(shù)據(jù)堆，把局部的臨時的變量都放進(jìn)去，生命周期和進(jìn)程有關(guān)系。但 是如果程序員聲明了static的變量，就直接在棧中運行的，進(jìn)程銷毀了，不一定會銷毀static變量。

另外為了保證java內(nèi)存不會溢出，java中有垃圾回收機(jī)制。System.gc()即垃圾收集機(jī)制是指jvm用于釋放那些不再使用的對象所占用的內(nèi)存。java語言并不要求jvm有g(shù)c，也沒有規(guī)定gc如何工作。垃圾收集的目的在于清除不再使用的對象。gc通過確定對象是否被活動對象引用來確定是否收集該對象。

而其中，內(nèi)存溢出就是你要求分配的java虛擬機(jī)內(nèi)存超出了系統(tǒng)能給你的，系統(tǒng)不能滿足需求，于是產(chǎn)生溢出。

內(nèi)存泄漏是指你向系統(tǒng)申請分配內(nèi)存進(jìn)行使用(new)，可是使用完了以后卻不歸還(delete)，結(jié)果你申請到的那塊內(nèi)存你自己也不能再訪問，該塊已分配出來的內(nèi)存也無法再使用，隨著服務(wù)器內(nèi)存的不斷消耗，而無法使用的內(nèi)存越來越 多，系統(tǒng)也不能再次將它分配給需要的程序，產(chǎn)生泄露。一直下去，程序也逐漸無內(nèi)存使用，就會溢出。

第二部分 原理

JAVA垃圾回收及對內(nèi)存區(qū)劃分

在Java虛擬機(jī)規(guī)范中，提及了如下幾種類型的內(nèi)存空間：

◇ 棧內(nèi)存(Stack)：每個線程私有的。

◇ 堆內(nèi)存(Heap)：所有線程公用的。

◇ 方法區(qū)(Method Area)：有點像以前常說的“進(jìn)程代碼段”，這里面存放了每個加載類的反射信息、類函數(shù)的代碼、編譯時常量等信息。

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

而Java的使用的是堆內(nèi)存，java堆是一個運行時數(shù)據(jù)區(qū)，類的實例(對象)從中分配空間。Java虛擬機(jī)(JVM)的堆中儲存著正在運行的應(yīng)用程序所建立的所有對象，“垃圾回收”也是主要是和堆內(nèi)存(Heap)有關(guān)。

垃圾回收的概念就是JAVA虛擬機(jī)(JVM)回收那些不再被引用的對象內(nèi)存的過程。一般我們認(rèn)為正在被引用的對象狀態(tài)為“alive”，而沒有 被應(yīng)用或者取不到引用屬性的對象狀態(tài)為“dead”。垃圾回收是一個釋放處于”dead”狀態(tài)的對象的內(nèi)存的過程。而垃圾回收的規(guī)則和算法被動態(tài)的作用于 應(yīng)用運行當(dāng)中，自動回收。

JVM的垃圾回收器采用的是一種分代(generational)回收策略，用較高的頻率對年輕的對象(young generation)進(jìn)行掃描和回收，這種叫做minor collection，而對老對象(old generation)的檢查回收頻率要低很多，稱為major collection。這樣就不需要每次GC都將內(nèi)存中所有對象都檢查一遍，這種策略有利于實時觀察和回收。

(Sun JVM 1.3 有兩種最基本的內(nèi)存收集方式：一種稱為copying或scavenge，將所有仍然生存的對象搬到另外一塊內(nèi)存后，整塊內(nèi)存就可回收。這種方法有效率，但需要有一定的空閑內(nèi)存，拷貝也有開銷。這種方法用于minor collection。另外一種稱為mark-compact，將活著的對象標(biāo)記出來，然后搬遷到一起連成大塊的內(nèi)存，其他內(nèi)存就可以回收了。這種方法不 需要占用額外的空間，但速度相對慢一些。這種方法用于major collection.)

一些對象被創(chuàng)建出來只是擁有短暫的生命周期，比如 iterators 和本地變量。

另外一些對象被創(chuàng)建是擁有很長的生命周期，比如 高持久化對象等。

垃圾回收器的分代策略是把內(nèi)存區(qū)劃分為幾個代，然后為每個代分配一到多個內(nèi)存區(qū)塊。當(dāng)其中一個代用完了分配給他的內(nèi)存后，JVM會在分配的內(nèi)存 區(qū)內(nèi)執(zhí)行一個局部的GC(也可以叫minor collection)操作，為了回收處于“dead”狀態(tài)的對象所占用的內(nèi)存。局部GC通常要不Full GC要快很多。

JVM定義了兩個代，年輕代(yong generation)(有時稱為“nursery”托兒所)和老年代(old generation)。年輕代包括 “Eden space(伊甸園)”和兩個“survivor spaces”。虛擬內(nèi)存初始化的時候會把所有對象都分配到 Eden space，并且大部分對象也會在該區(qū)域被釋放。當(dāng)進(jìn)行 minor GC的時候，VM會把剩下的沒有釋放的對象從Eden space移動到其中一個survivor spaces當(dāng)中。此外，VM也會把那些長期存活在survivor spaces 里的對象移動到 老生代的“tenured” space中。當(dāng) tenured generation 被填滿后，就會產(chǎn)生Full GC，F(xiàn)ull GC會相對比較慢因為回收的內(nèi)容包括了所有的 live狀態(tài)的對象。pemanet generation這個代包括了所有java虛擬機(jī)自身使用的相對比較穩(wěn)定的數(shù)據(jù)對象，比如類和對象方法等。

關(guān)于代的劃分，可以從下圖中獲得一個概況：

如果垃圾回收器影響了系統(tǒng)的性能，或者成為系統(tǒng)的瓶頸，你可以通過自定義各個代的大小來優(yōu)化它的性能。使用JConsole，可以方便的查看到當(dāng)前應(yīng)用所配置的垃圾回收器的各個參數(shù)。想要獲得更詳細(xì)的參數(shù)，可以參考以下調(diào)優(yōu)介紹：

Tuning Garbage collection with the 5.0 HotSpot VM

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

最后，總結(jié)一下各區(qū)內(nèi)存：

Eden Space(heap)： 內(nèi)存最初從這個線程池分配給大部分對象。

Survivor Space(heap)：用于保存在eden space內(nèi)存池中經(jīng)過垃圾回收后沒有被回收的對象。

Tenured Generation(heap)：用于保持已經(jīng)在 survivor space內(nèi)存池中存在了一段時間的對象。

Permanent Generation(non-heap): 保存虛擬機(jī)自己的靜態(tài)(refective)數(shù)據(jù)，例如類(class)和方法(method)對象。Java虛擬機(jī)共享這些類數(shù)據(jù)。這個區(qū)域被分割為只讀的和只寫的，Code Cache(non-heap):HotSpot Java虛擬機(jī)包括一個用于編譯和保存本地代碼(native code)的內(nèi)存，叫做“代碼緩存區(qū)”(code cache)

第三部分 監(jiān)控(工具發(fā)現(xiàn)問題)

談到內(nèi)存監(jiān)控工具，JConsole是必須要介紹的，它是一個用JAVA寫的GUI程序，用來監(jiān)控 VM，并可監(jiān)控遠(yuǎn)程的VM，易用且功能強(qiáng)大。具體可監(jiān)控JAVA內(nèi)存、JAVA CPU使用率、線程執(zhí)行情況、加載類概況等，Jconsole需要在JVM參數(shù)中配置端口才能使用。

由于是GUI程序，界面可視化，這里就不做詳細(xì)介紹，具體幫助支持文檔請參閱性能測試JConsole使用方法總結(jié)：

http://

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

在實際測試某一個項目時，內(nèi)存出現(xiàn)泄露現(xiàn)象。起初在性能測試的1個小時中，并不明顯，而在穩(wěn)定性測試的時候才發(fā)現(xiàn)，應(yīng)用的HSF調(diào)用在經(jīng)過幾個 小時運行后，就出現(xiàn)性能明顯下降的情況。在服務(wù)日志中報大量HSF超時，但所調(diào)用系統(tǒng)沒有任何超時日志，并且壓力應(yīng)用的load都很低。經(jīng)過查看日志后，認(rèn)為應(yīng)用可能存在內(nèi)存泄漏。通過jconsole 以及 jmap 工具進(jìn)行分析發(fā)現(xiàn)，確實存在內(nèi)存泄漏問題，其中PS Old Gen最終達(dá)到占用 100%的占用。如圖所示：

從上圖可以看到，雖然每次Full GC，JVM內(nèi)存會有部分回收，但回收并不徹底，不可回收的內(nèi)存對象會越來越多，這樣便會出現(xiàn)以上的一個趨勢。在Full GC無法回收的對象越來越多時，最終已使用內(nèi)存達(dá)到系統(tǒng)分配的內(nèi)存最大值，系統(tǒng)最后無內(nèi)存可分配，最終down機(jī)。

第四部分 分析

經(jīng)過開發(fā)和架構(gòu)師對應(yīng)用的分析，查看此時內(nèi)存隊列，看哪個對象占用數(shù)據(jù)最多，再利用jmap命令，對線程數(shù)據(jù)分析，如下所示：

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不斷增加，指代的是同一個代碼邏輯，異步分發(fā)的問題，堵塞消息，回收多次都無法回收成功。導(dǎo)致內(nèi)存溢出。

此外，對應(yīng)用的性能單獨做了壓測，他的性能只能支撐到一半左右，故發(fā)送消息的TPS，應(yīng)用肯定無法處理過來，導(dǎo)致消息堆積，而JAVA垃圾回收期認(rèn)為這些都是有用的對象，導(dǎo)致內(nèi)存堆積，直至系統(tǒng)崩潰。

調(diào)優(yōu)方法

由于具體調(diào)優(yōu)方法涉及到應(yīng)用的配置信息，故在此暫不列出，可以參考性能測試小組發(fā)布的《性能測試調(diào)優(yōu)寶典》

第四部分 總結(jié)

內(nèi)存溢出主要是由于代碼編寫時對某些方法、類應(yīng)用不合理，或者沒有預(yù)估到臨時對象會占用很大內(nèi)存量，或者把過多的數(shù)據(jù)放入JVM緩存，或者性能 壓力大導(dǎo)致消息堆積而占用內(nèi)存，以至于在性能測試時，生成龐大數(shù)量的臨時對象，GC時沒有做出有效回收甚至根本就不能回收，造成內(nèi)存空間不足，內(nèi)存溢出。

如果編碼之前，對內(nèi)存使用量進(jìn)行預(yù)估，對放在內(nèi)存中的數(shù)據(jù)進(jìn)行評估，保證有用的信息盡快釋放，無用的信息能夠被GC回收，這樣在一定程度上是可以避免內(nèi)存溢出問題的。

第三篇：性能測試總結(jié)之內(nèi)存泄露和內(nèi)存溢出

性能測試總結(jié)之內(nèi)存泄露和內(nèi)存溢出

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

剛剛做完了一個項目的性能測試，“有幸”也遇到了內(nèi)存泄露的案例，所以在此和大家分享一下。

主要從以下幾部分來說明，關(guān)于內(nèi)存和內(nèi)存泄露、溢出的概念，區(qū)分內(nèi)存泄露和內(nèi)存溢出；內(nèi)存的區(qū)域劃分，了解GC回收機(jī)制；重點關(guān)注如何去監(jiān)控內(nèi)存問題；此外分析出問題還要如何解決內(nèi)存問題。下面就開始本篇的內(nèi)容： 第一部分 概念

眾所周知，java中的內(nèi)存java虛擬機(jī)自己去管理的，他不想C++需要自己去釋放?；\統(tǒng)地去講，java的內(nèi)存分配分為兩個部分，一個是數(shù)據(jù)堆，一個是序在運行的時候一般分配數(shù)據(jù)堆，把局部的臨時的變量都放進(jìn)去，生命周期和進(jìn)程有關(guān)系。但是如果程序員聲明了static的變量，就直接在棧中運行的，進(jìn)了，不一定會銷毀static變量。

另外為了保證java內(nèi)存不會溢出，java中有垃圾回收機(jī)制。System.gc()即垃圾收集機(jī)制是指jvm用于釋放那些不再使用的對象所占用的內(nèi)存。java語言求jvm有g(shù)c，也沒有規(guī)定gc如何工作。垃圾收集的目的在于清除不再使用的對象。gc通過確定對象是否被活動對象引用來確定是否收集該對象。而其中，內(nèi)存溢出就是你要求分配的java虛擬機(jī)內(nèi)存超出了系統(tǒng)能給你的，系統(tǒng)不能滿足需求，于是產(chǎn)生溢出。

內(nèi)存泄漏是指你向系統(tǒng)申請分配內(nèi)存進(jìn)行使用(new)，可是使用完了以后卻不歸還(delete)，結(jié)果你申請到的那塊內(nèi)存你自己也不能再訪問,該塊已分配出存也無法再使用，隨著服務(wù)器內(nèi)存的不斷消耗，而無法使用的內(nèi)存越來越多，系統(tǒng)也不能再次將它分配給需要的程序，產(chǎn)生泄露。一直下去，程序也逐漸使用，就會溢出。第二部分 原理

JAVA垃圾回收及對內(nèi)存區(qū)劃分

在Java虛擬機(jī)規(guī)范中，提及了如下幾種類型的內(nèi)存空間： ◇ 棧內(nèi)存（Stack）：每個線程私有的?！?堆內(nèi)存（Heap）：所有線程公用的。

◇ 方法區(qū)（Method Area）：有點像以前常說的“進(jìn)程代碼段”，這里面存放了每個加載類的反射信息、類函數(shù)的代碼、編譯時常量等信息?！?原生方法棧（Native Method Stack）：主要用于JNI中的原生代碼，平時很少涉及。

而Java的使用的是堆內(nèi)存，java堆是一個運行時數(shù)據(jù)區(qū)，類的實例(對象)從中分配空間。Java虛擬機(jī)(JVM)的堆中儲存著正在運行的應(yīng)用程序所建立的象，“垃圾回收”也是主要是和堆內(nèi)存（Heap）有關(guān)。

垃圾回收的概念就是JAVA虛擬機(jī)（JVM）回收那些不再被引用的對象內(nèi)存的過程。一般我們認(rèn)為正在被引用的對象狀態(tài)為“alive”,而沒有被應(yīng)用或者取用屬性的對象狀態(tài)為“dead”。垃圾回收是一個釋放處于”dead”狀態(tài)的對象的內(nèi)存的過程。而垃圾回收的規(guī)則和算法被動態(tài)的作用于應(yīng)用運行當(dāng)中，自動回JVM的垃圾回收器采用的是一種分代（generational）回收策略，用較高的頻率對年輕的對象(young generation)進(jìn)行掃描和回收，這種叫做minor collec對老對象(old generation)的檢查回收頻率要低很多，稱為major collection。這樣就不需要每次GC都將內(nèi)存中所有對象都檢查一遍，這種策略有利于實時觀收。

（Sun JVM 1.3 有兩種最基本的內(nèi)存收集方式：一種稱為copying或scavenge，將所有仍然生存的對象搬到另外一塊內(nèi)存后，整塊內(nèi)存就可回收。這種效率，但需要有一定的空閑內(nèi)存，拷貝也有開銷。這種方法用于minor collection。另外一種稱為mark-compact，將活著的對象標(biāo)記出來，然后搬遷到一起塊的內(nèi)存，其他內(nèi)存就可以回收了。這種方法不需要占用額外的空間，但速度相對慢一些。這種方法用于major collection.）一些對象被創(chuàng)建出來只是擁有短暫的生命周期，比如 iterators 和本地變量。另外一些對象被創(chuàng)建是擁有很長的生命周期，比如 高持久化對象等。

垃圾回收器的分代策略是把內(nèi)存區(qū)劃分為幾個代，然后為每個代分配一到多個內(nèi)存區(qū)塊。當(dāng)其中一個代用完了分配給他的內(nèi)存后，JVM會在分配的內(nèi)存行一個局部的GC（也可以叫minor collection）操作，為了回收處于“dead”狀態(tài)的對象所占用的內(nèi)存。局部GC通常要不Full GC要快很多。

JVM定義了兩個代，年輕代（yong generation）（有時稱為“nursery”托兒所）和老年代(old generation)。年輕代包括 “Eden space（伊甸園）”和兩個“survivor虛擬內(nèi)存初始化的時候會把所有對象都分配到 Eden space，并且大部分對象也會在該區(qū)域被釋放。當(dāng)進(jìn)行 minor GC的時候，VM會把剩下的沒有釋放的Eden space移動到其中一個survivor spaces當(dāng)中。此外，VM也會把那些長期存活在survivor spaces 里的對象移動到 老生代的“tenured” space中。當(dāng) tenured g被填滿后，就會產(chǎn)生Full GC，F(xiàn)ull GC會相對比較慢因為回收的內(nèi)容包括了所有的 live狀態(tài)的對象。pemanet generation這個代包括了所有java虛擬機(jī)自身相對比較穩(wěn)定的數(shù)據(jù)對象，比如類和對象方法等。關(guān)于代的劃分，可以從下圖中獲得一個概況：

如果垃圾回收器影響了系統(tǒng)的性能，或者成為系統(tǒng)的瓶頸，你可以通過自定義各個代的大小來優(yōu)化它的性能。使用JConsole，可以方便的查看到當(dāng)前應(yīng)置的垃圾回收器的各個參數(shù)。想要獲得更詳細(xì)的參數(shù)，可以參考以下調(diào)優(yōu)介紹： Tuning Garbage collection with the 5.0 HotSpot VM http://java.sun.com/docs/hotspot/gc/index.html 最后，總結(jié)一下各區(qū)內(nèi)存：

Eden Space(heap)： 內(nèi)存最初從這個線程池分配給大部分對象。

Survivor Space(heap)：用于保存在eden space內(nèi)存池中經(jīng)過垃圾回收后沒有被回收的對象。Tenured Generation(heap)：用于保持已經(jīng)在 survivor space內(nèi)存池中存在了一段時間的對象。

Permanent Generation(non-heap): 保存虛擬機(jī)自己的靜態(tài)(refective)數(shù)據(jù)，例如類（class）和方法（method）對象。Java虛擬機(jī)共享這些類數(shù)據(jù)。這個區(qū)割為只讀的和只寫的，Code Cache(non-heap):HotSpot Java虛擬機(jī)包括一個用于編譯和保存本地代碼（native code）的內(nèi)存，叫做“代碼緩存區(qū)”（code cache）第三部分 監(jiān)控（工具發(fā)現(xiàn)問題）

談到內(nèi)存監(jiān)控工具，JConsole是必須要介紹的，它是一個用JAVA寫的GUI程序，用來監(jiān)控VM，并可監(jiān)控遠(yuǎn)程的VM，易用且功能強(qiáng)大。具體可監(jiān)控內(nèi)存、JAVA CPU使用率、線程執(zhí)行情況、加載類概況等，Jconsole需要在JVM參數(shù)中配置端口才能使用。由于是GUI程序，界面可視化，這里就不做詳細(xì)介紹，具體幫助支持文檔請參閱性能測試JConsole使用方法總結(jié)：

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

在實際測試某一個項目時，內(nèi)存出現(xiàn)泄露現(xiàn)象。起初在性能測試的1個小時中，并不明顯，而在穩(wěn)定性測試的時候才發(fā)現(xiàn)，應(yīng)用的HSF調(diào)用在經(jīng)過幾個行后，就出現(xiàn)性能明顯下降的情況。在服務(wù)日志中報大量HSF超時，但所調(diào)用系統(tǒng)沒有任何超時日志，并且壓力應(yīng)用的load都很低。經(jīng)過查看日志后，認(rèn)可能存在內(nèi)存泄漏。通過jconsole 以及 jmap 工具進(jìn)行分析發(fā)現(xiàn)，確實存在內(nèi)存泄漏問題，其中PS Old Gen最終達(dá)到占用 100%的占用。如圖所示：

從上圖可以看到，雖然每次Full GC，JVM內(nèi)存會有部分回收，但回收并不徹底，不可回收的內(nèi)存對象會越來越多，這樣便會出現(xiàn)以上的一個趨勢。在無法回收的對象越來越多時，最終已使用內(nèi)存達(dá)到系統(tǒng)分配的內(nèi)存最大值，系統(tǒng)最后無內(nèi)存可分配，最終down機(jī)。第四部分 分析

經(jīng)過開發(fā)和架構(gòu)師對應(yīng)用的分析，查看此時內(nèi)存隊列，看哪個對象占用數(shù)據(jù)最多，再利用jmap命令，對線程數(shù)據(jù)分析，如下所示： 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不斷增加，指代的是同一個代碼邏輯，異步分發(fā)的問題，堵塞消息，回收多次都無法回收成功。導(dǎo)致內(nèi)存溢出。此外，對應(yīng)用的性能單獨做了壓測，他的性能只能支撐到一半左右，故發(fā)送消息的TPS，應(yīng)用肯定無法處理過來，導(dǎo)致消息堆積，而JAVA垃圾回收期些都是有用的對象，導(dǎo)致內(nèi)存堆積，直至系統(tǒng)崩潰。

調(diào)優(yōu)方法

由于具體調(diào)優(yōu)方法涉及到應(yīng)用的配置信息，故在此暫不列出，可以參考性能測試小組發(fā)布的《性能測試調(diào)優(yōu)寶典》 第四部分 總結(jié)

內(nèi)存溢出主要是由于代碼編寫時對某些方法、類應(yīng)用不合理，或者沒有預(yù)估到臨時對象會占用很大內(nèi)存量，或者把過多的數(shù)據(jù)放入JVM緩存，或者性大導(dǎo)致消息堆積而占用內(nèi)存，以至于在性能測試時，生成龐大數(shù)量的臨時對象，GC時沒有做出有效回收甚至根本就不能回收，造成內(nèi)存空間不足，內(nèi)存如果編碼之前，對內(nèi)存使用量進(jìn)行預(yù)估，對放在內(nèi)存中的數(shù)據(jù)進(jìn)行評估，保證有用的信息盡快釋放，無用的信息能夠被GC回收，這樣在一定程度上是免內(nèi)存溢出問題的。

第四篇：Linux系統(tǒng)內(nèi)存使用的體會及命令解釋

Linux系統(tǒng)內(nèi)存使用的體會及命令解釋

發(fā)布時間：2006.09.26 04:45來源：chinaunix.net作者：nonameboy

Linux的內(nèi)存管理，實際上跟windows的內(nèi)存管理有很相像的地方，都是用虛擬內(nèi)存這個的概念，說到這里不得不罵MS，為什么在很多時候還有很大的物理內(nèi)存的時候，卻還是用到了pagefile.所以才經(jīng)常要跟一幫人吵著說Pagefile的大小，以及如何分配這個問題，在Linux大家就不用再吵什么swap大小的問題，我個人認(rèn)為，swap設(shè)個512M已經(jīng)足夠了，如果你問說512M的SWAP不夠用怎么辦？只能說大哥你還是加內(nèi)存吧，要不就檢查你的應(yīng)用，是不是真的出現(xiàn)了memory leak.夜也深了，就不再說廢話了。

在Linux下查看內(nèi)存我們一般用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；

下面是對這些數(shù)值的解釋：

total:總計物理內(nèi)存的大小。

used:已使用多大。

free:可用有多少。

Shared:多個進(jìn)程共享的內(nèi)存總額。

Buffers/cached:磁盤緩存的大小。

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

used:已使用多大。

free:可用有多少。

第四行就不多解釋了。

區(qū)別：第二行(mem)的used/free與第三行(-/+ buffers/cache)used/free的區(qū)別。這兩個的區(qū)別在于使用的角度來看，第一行是從OS的角度來看，因為對于OS，buffers/cached 都是屬于被使用，所以他的可用內(nèi)存是8908KB,已用內(nèi)存是377116KB,其中包括，內(nèi)核（OS）使用+Application(X,oracle,etc)使用的+buffers+cached.第三行所指的是從應(yīng)用程序角度來看，對于應(yīng)用程序來說，buffers/cached 是等于可用的，因為buffer/cached是為了提高文件讀取的性能，當(dāng)應(yīng)用程序需在用到內(nèi)存的時候，buffer/cached會很快地被回收。

所以從應(yīng)用程序的角度來說，可用內(nèi)存=系統(tǒng)free memory+buffers+cached。如上例：

185656=8908+21280+155468 接下來解釋什么時候內(nèi)存會被交換，以及按什么方交換。當(dāng)可用內(nèi)存少于額定值的時候，就會開會進(jìn)行交換。如何看額定值（RHEL4.0）：

#cat /proc/meminfo

交換將通過三個途徑來減少系統(tǒng)中使用的物理頁面的個數(shù)：

1.減少緩沖與頁面cache的大小，2.將系統(tǒng)V類型的內(nèi)存頁面交換出去，3.換出或者丟棄頁面。(Application 占用的內(nèi)存頁，也就是物理內(nèi)存不足）。事實上，少量地使用swap是不是影響到系統(tǒng)性能的。

下面是buffers與cached的區(qū)別。

buffers是指用來給塊設(shè)備做的緩沖大小，他只記錄文件系統(tǒng)的metadata以及 tracking in-flight pages.cached是用來給文件做緩沖。那就是說：buffers是用來存儲，目錄里面有什么內(nèi)容，權(quán)限等等。而cached直接用來記憶我們打開的文件，如果你想知道他是不是真的生效，你可以試一下，先后執(zhí)行兩次命令#man X ,你就可以明顯的感覺到第二次的開打的速度快很多。

實驗：在一臺沒有什么應(yīng)用的機(jī)器上做會看得比較明顯。記得實驗只能做一次，如果想多做請換一個文件名。

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

你可以先后比較一下free后顯示buffers的大小。另一個實驗：

#free #ls /dev #free

你比較一下兩個的大小，當(dāng)然這個buffers隨時都在增加，但你有l(wèi)s過的話，增加的速度會變得快，這個就是buffers/chached的區(qū)別。

第五篇：校園監(jiān)控系統(tǒng)整體解決

校園監(jiān)控系統(tǒng)整體解決

設(shè) 計 方 案

2011年1月22日

一、現(xiàn)狀分析

現(xiàn)在各地市的學(xué)校都普遍存在著校園面積大、場地分散，學(xué)生眾多，學(xué)校大門口人流混亂，而且有的學(xué)校大門臨街建設(shè)，很容易出現(xiàn)交通事故，也有部分社會不良青年聚集學(xué)校門口滋事，校園周邊的環(huán)境復(fù)雜等問題。近年來校園暴力事件和突發(fā)事故的增加，傳統(tǒng)的人力巡查已不能滿足校園安全管理的需求，越來越多的學(xué)校開始考慮通過校園網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)的實施來建設(shè)平安校園。

二、實際需求

隨著學(xué)校的信息化建設(shè)不斷深入，各學(xué)校都加快了信息網(wǎng)絡(luò)平臺的建設(shè);學(xué)校正逐步轉(zhuǎn)向利用網(wǎng)絡(luò)和計算機(jī)集中處理管理、服務(wù)等重要環(huán)節(jié)的大量數(shù)據(jù)。另外，隨著應(yīng)用的深入，很多校園安全提出了越來越高的要求，紛紛建立校區(qū)的網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)，為整個學(xué)校的工作、安全防衛(wèi)提供了一套實時視頻監(jiān)控，事件視頻取證的平臺工具。

數(shù)字視頻、音頻以其直觀性、易于存儲、檢索和共享，是學(xué)?？梢曅畔⒐芾硐到y(tǒng)的重要組成部分。IP視頻監(jiān)控系統(tǒng)是基于網(wǎng)絡(luò)平臺的有關(guān)安防、管理的音視頻數(shù)據(jù)的管理系統(tǒng)，它是傳統(tǒng)視頻監(jiān)控系統(tǒng)在功能上不斷進(jìn)步完善的產(chǎn)物，在平臺結(jié)構(gòu)和管理、視頻資料安全方面功能強(qiáng)大，擺脫了傳統(tǒng)模擬視頻監(jiān)控模式的大量弊端，是未來視頻監(jiān)控的發(fā)展方向。IVSPNET 網(wǎng)絡(luò)視頻監(jiān)控管理平臺就是一個基于網(wǎng)絡(luò)平臺，以多級聯(lián)網(wǎng)管理支持分布式應(yīng)用的綜合性網(wǎng)絡(luò)視頻監(jiān)控管理系統(tǒng)。特別適合學(xué)校的局部自治，中心掌控全局的多級聯(lián)網(wǎng)應(yīng)用管理平臺軟件。

三、系統(tǒng)概述

IVSPNET 網(wǎng)絡(luò)視頻監(jiān)控管理平臺是一個以多級聯(lián)網(wǎng)管理并支持分布式應(yīng)用的綜合性網(wǎng)絡(luò)視頻監(jiān)控管理系統(tǒng)。特別適合局部自治，中心掌控全局的多級聯(lián)網(wǎng)應(yīng)用。它具有客戶端與服務(wù)器兩部分，服務(wù)器又包括核心服務(wù)器、設(shè)備代理/消息服務(wù)器、流媒體服務(wù)器、二級轉(zhuǎn)發(fā)服務(wù)器。功能有

集中監(jiān)控與數(shù)字矩陣、回放下載、系統(tǒng)配置、電子地圖、報警采集與聯(lián)動等功能。同時，它具有兼容多廠家品牌視頻設(shè)備的能力，目前可以兼容?？等盗?包括最新的9000系列)、大華、恒億、朗馳相關(guān)的DVR、DVS、IPCAM。還具有良好的聯(lián)動功能，不同的設(shè)備可任意聯(lián)動，使系統(tǒng)能夠協(xié)同工作，對異常情況能夠及時有效地處理。其主要具有以下特性：

3.1.1設(shè)計思想的先進(jìn)性

本系統(tǒng)一方面提升技防的科技含量，實現(xiàn)學(xué)校安全保衛(wèi)手段的現(xiàn)代化。通過本系統(tǒng)，實現(xiàn)校園安全保衛(wèi)由勞動密集性向知識密集型的轉(zhuǎn)化，提升安全系數(shù)和防范效率；

另一方面是深化監(jiān)控中心職能，實現(xiàn)校園內(nèi)控監(jiān)管的現(xiàn)代化。將監(jiān)控中心由原先單純的監(jiān)控和威懾轉(zhuǎn)變到內(nèi)控管理、業(yè)務(wù)監(jiān)督等多重功能上來，將技術(shù)領(lǐng)先的優(yōu)勢擴(kuò)大到內(nèi)控監(jiān)管上來，有效整合和合理利用現(xiàn)有資源，使之成為學(xué)校的信息中心、控制中心、管理中心、從而大大提高學(xué)校整體工作的集約化水平和工作效率。

3.1.2系統(tǒng)平臺的統(tǒng)一性和功能的完備性

系統(tǒng)應(yīng)為管理者和使用者提供統(tǒng)一的操作平臺，讓使用更加方便，直觀顯示操作的結(jié)果。學(xué)校內(nèi)共有圖像監(jiān)視、防盜報警、燈光電源管理、空調(diào)控制等系統(tǒng)，從管理和使用角度考慮，應(yīng)在一個統(tǒng)一的平臺上面來控制，而不需控制多種設(shè)備而啟動多個控制系統(tǒng)；

從系統(tǒng)的功能模塊構(gòu)成上看，包含電子地圖、語音對講、語音廣播、DVR遠(yuǎn)程管理、遠(yuǎn)程監(jiān)看圖像、遠(yuǎn)程控制照明等設(shè)備、系統(tǒng)日志……等等，應(yīng)能夠除監(jiān)控設(shè)備以外能夠控制監(jiān)控周邊設(shè)備。

3.1.3系統(tǒng)運行的穩(wěn)定性和可靠性

多級的系統(tǒng)架構(gòu)，保證了系統(tǒng)的穩(wěn)定運行；

具有設(shè)計獨到的視頻流及數(shù)據(jù)流管理功能，保證網(wǎng)絡(luò)連接通暢；

系統(tǒng)具有自診斷和調(diào)節(jié)功能，保證系統(tǒng)運行于正常狀態(tài)；

同時，系統(tǒng)應(yīng)得到學(xué)校應(yīng)用的考驗。系統(tǒng)設(shè)備的平均無故障工作時間MTBF>10000小時。

3.1.4前端設(shè)備的兼容性

系統(tǒng)兼容性和開放性：主要體現(xiàn)在軟件可與前端的各種不同生產(chǎn)廠家的設(shè)備（DVR /DVS/IP CAMERA）兼容。

軟件兼容市場上主流板卡（海康威視M/H/HC卡、恒億6000/4000卡等），視頻解碼軟件兼容?？低昅D卡、7000卡、8000卡等、在建設(shè)監(jiān)控中心時，只要是上述板卡，僅需換上本軟件，不需更換硬件即可；

本軟件同時兼容?？低?、浙江大華、武漢恒憶等市場上銷售的大部分具有網(wǎng)絡(luò)功能的嵌入式DVR。

兼容性的意義：對前期改造項目而言，連鎖店（學(xué)校）可避免重復(fù)建設(shè)的投資，節(jié)約成本。系統(tǒng)集成商的解決方案靈活，不會受制于人；對后續(xù)建設(shè)網(wǎng)點來說，連鎖店（學(xué)校）不會被某一家設(shè)備供應(yīng)商牽制，可選擇市場上性價比最好的產(chǎn)品。

3.1.5系統(tǒng)的擴(kuò)展性

為了適應(yīng)未來系統(tǒng)擴(kuò)展的要求，系統(tǒng)在滿足現(xiàn)有功能的基礎(chǔ)上預(yù)留足夠的設(shè)備容納性以便系統(tǒng)擴(kuò)充之用。系統(tǒng)中控制部件（軟、硬件）采用集中式結(jié)構(gòu)、嵌入式模塊等技術(shù)措施，方便靈活的進(jìn)行擴(kuò)充，充分保證系統(tǒng)在將來的適應(yīng)性；

靈活的組網(wǎng)方式，方便被監(jiān)控點的增加；

多級架構(gòu)可以把連鎖店（學(xué)校）組成更大的視頻監(jiān)控系統(tǒng)，形成大規(guī)模的監(jiān)控網(wǎng)絡(luò)，連鎖總店（學(xué)校）監(jiān)控中心能管理和監(jiān)控分學(xué)校的運行，具有較強(qiáng)的適應(yīng)性和可擴(kuò)充性。

3.1.6易用性和易維護(hù)

系統(tǒng)硬件平臺為標(biāo)準(zhǔn)2U/4U服務(wù)器，硬件連接采用標(biāo)準(zhǔn)化接口，高度工程化，便于施工、安裝、調(diào)試；

系統(tǒng)的軟件操作簡便，能應(yīng)用于Windows2000/NT/XP/2003等操作系統(tǒng)，方便連鎖店（學(xué)校）人員的使用和系統(tǒng)的日常維護(hù)；

軟件使用界面良好，用戶安裝相應(yīng)軟件后就可進(jìn)行實現(xiàn)監(jiān)控，完全智能控制，不用單獨設(shè)置；

系統(tǒng)可以很方便進(jìn)行軟件升級，保證用戶投資。系統(tǒng)采用的軟件，包括：服務(wù)器軟件和客戶端軟件，均為客戶提供升級服務(wù)。

四、系統(tǒng)主要功能特色及優(yōu)勢服務(wù)

IVSPNET 網(wǎng)絡(luò)視頻監(jiān)控管理平臺是基于計算機(jī)網(wǎng)絡(luò)、圖像編解碼、數(shù)據(jù)通信、控制及監(jiān)控技術(shù)等領(lǐng)域而自主開發(fā)的全數(shù)字化網(wǎng)絡(luò)遠(yuǎn)程集中監(jiān)控管理平臺。此平臺采用分布、多級網(wǎng)絡(luò)互聯(lián)設(shè)計，基于Intranet/Internet架構(gòu)、采用客戶端/服務(wù)器模式(Client/Server)與瀏覽器/服務(wù)器(Browser/Server)模式，通過TCP/IP協(xié)議的模塊化結(jié)構(gòu)設(shè)計，根據(jù)不同用戶需求靈活配置和定制。

4.1.IVSPNET 網(wǎng)絡(luò)視頻監(jiān)控管理平臺主要特色

4.1.1集中管理

一般情況下，大型的學(xué)校需要集中管理各個分校，IVSPNET-很好地滿足了這一需求，完善的權(quán)限管理機(jī)制和流媒體轉(zhuǎn)播技術(shù)，可以在任何需要建立分控中心的地方設(shè)立監(jiān)視工作站或監(jiān)視器，系統(tǒng)提供按照需要為各分學(xué)校及用戶靈活分配權(quán)限及可查看攝像機(jī)的能力，使監(jiān)視系統(tǒng)完全與日常工作相符合。

4.1.2適應(yīng)性強(qiáng)

在技術(shù)上，IVSPNET不僅可以適應(yīng)復(fù)雜的網(wǎng)絡(luò)環(huán)境，而且可以將視頻圖像從前端設(shè)備通過流媒體服務(wù)器，直接以組播流的形式發(fā)送給多個用戶，大大降低了對網(wǎng)絡(luò)資源的占用。監(jiān)視界面不僅支持多種分割顯示方式，而且可以根據(jù)需要建立多個分割顯示畫面（布局頁），各分割顯示畫面之間可以手動或自動順序切換，這樣即使監(jiān)視點數(shù)很多，也可通過一個工作站來快速查看所有的攝像機(jī)圖像。

4.1.3網(wǎng)絡(luò)兼容性強(qiáng)

視頻傳輸是基于TCP/IP協(xié)議，可跨越網(wǎng)關(guān)及路由，適應(yīng)不同的網(wǎng)絡(luò)環(huán)境。此外，利用流媒體DVR，通過真正的流媒體技術(shù)，可以適應(yīng)窄帶傳輸，從而對任何有IP網(wǎng)絡(luò)連通的任何地方都可以實現(xiàn)監(jiān)控。

4.1.4軟硬件同時解碼顯示

IVSPNET支持軟、硬件同時對視頻流進(jìn)行解碼顯示，很好地兼容數(shù)字（顯示器、背投、大屏幕）與模擬監(jiān)視設(shè)備（監(jiān)視器），從而非常方便地建立集中監(jiān)控中心與多個分散的分控中心。實現(xiàn)了軟硬結(jié)合，實時性、可靠性與靈活性、實用性并存。

4.1.5音視頻同步

IVSPNET可以集成全雙工語音通信功能，實現(xiàn)音視頻同步監(jiān)控、雙向通話及語音廣播功能。

4.1.6支持IE瀏覽

IVSPNET內(nèi)部有WEB服務(wù)器，用戶可以直接用IE瀏覽器訪問設(shè)備以查看視頻圖像或配置設(shè)備，也可以通過IE瀏覽器登錄系統(tǒng)服務(wù)器（Directory Server），以獲取攝像機(jī)列表，點擊其中一個即可查看視頻圖像或控制攝像機(jī)上、下、左、右轉(zhuǎn)動。

4.1.7強(qiáng)大的電子地圖

IVSPNET支持電子地圖，可以將各攝像機(jī)、輸入開關(guān)、輸出開關(guān)、子電子地圖位置映射在電子地圖上，當(dāng)點擊電子地圖上的圖標(biāo)時，該圖標(biāo)所對應(yīng)的圖像會自動彈出。支持電子地圖專題標(biāo)繪，直觀表現(xiàn)現(xiàn)場環(huán)境，與報警接收聯(lián)動等功能完美集成在一起，支持查詢分類專題點，放大與縮小平移電子地圖。

本功能的使用需要建立在系統(tǒng)配置功能配好各項數(shù)據(jù)的前提下使用。支持多級電子地圖使用。

4.2.IVSPNET網(wǎng)絡(luò)視頻監(jiān)控管理平臺的主要功能：

IVSPNET 網(wǎng)絡(luò)視頻監(jiān)控管理平臺可以對學(xué)校中不同廠家的設(shè)備的各種重要信息進(jìn)行綜合處理，生成安防系統(tǒng)管理所需要的綜合數(shù)據(jù)庫，從而對所有全局事件進(jìn)行集中管理。因此，在學(xué)校的總控制中心的管理計算機(jī)上，可以得到各個分校的有關(guān)的數(shù)據(jù)，并將關(guān)系到各個分學(xué)校正常運行、重要的報警信息匯集上來，得到統(tǒng)一的管理，定期輸出設(shè)備運行及管理的各類報表，為集成系統(tǒng)設(shè)備的正常、經(jīng)濟(jì)運行提供可靠、完整的依據(jù)，同時將所有分學(xué)校之間需要共享的數(shù)據(jù)收集上來，存儲到統(tǒng)一的開放式數(shù)據(jù)庫當(dāng)中，實現(xiàn)各學(xué)校之間的信息共享和集中的設(shè)備監(jiān)控、報警管理和聯(lián)動控制功能。

該系統(tǒng)監(jiān)控平臺由音視頻監(jiān)控、電子地圖管理、語音及廣播管理、模擬數(shù)字矩陣、報警遠(yuǎn)程聯(lián)動、遠(yuǎn)程電動設(shè)備控制管理等系統(tǒng)組成，實現(xiàn)多系統(tǒng)統(tǒng)一平臺的集中控制和管理。

主要功能如下：

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?遠(yuǎn)程視頻輪巡顯示及監(jiān)視功能；

?紅外、煙感、玻璃破碎、有毒汽體報警功能； ?遠(yuǎn)程布/撤防和報警聯(lián)動上傳功能； ?雙向語音對講及廣播功能； ?遠(yuǎn)程實時查看圖像、實時錄像； ?遠(yuǎn)程錄像資料檢索及數(shù)據(jù)備份；

?遠(yuǎn)程對前端設(shè)備進(jìn)行重啟、注冊、注銷、配置、校時功能； ?遠(yuǎn)程開關(guān)量輸出及燈光/空調(diào)等設(shè)備控制功能； ?具有多種報警聯(lián)動方式和報警控制功能；

?分布式網(wǎng)絡(luò)視頻接入，集中權(quán)限控制和資源管理，多級組織結(jié)構(gòu)等功能；

?前端設(shè)備IP自動上傳功能（動態(tài)IP）； ?模擬數(shù)字矩陣視頻上墻功能； ?強(qiáng)大的電子地圖功能； ?日志文檔分類管理和檢索；

?流媒體轉(zhuǎn)播、二級中轉(zhuǎn)及多級分控中心和不同需求內(nèi)控功能； ?兼容和整合其它系統(tǒng)，實現(xiàn)資源共享，達(dá)到操作簡便。

4.3.IVSPNET網(wǎng)絡(luò)視頻監(jiān)控管理平臺優(yōu)勢服務(wù)；

4.3.1顯示服務(wù)

? 顯示管理 ? ? 該部分相當(dāng)于一個數(shù)字視頻顯示矩陣。

與配置服務(wù)器配合工作，決定畫面顯示策略（固定、輪切、插播顯示）和屏幕的分屏方式（1、4、9、16分屏方式）； ? 與配置服務(wù)器配合工作，決定前端的某路圖像上電視墻，同時顯示在屏幕上的某個位置，何時顯示。

? 畫面顯示 ? 純解碼功能，需要硬件配置，根據(jù)解碼方式可分為：

? 數(shù)字顯示：即利用計算機(jī)軟件解碼后將圖像顯示到顯示器上。數(shù)字顯示可在同一屏幕顯示任意不同品牌板卡視頻圖像的組合。

? 模擬顯示：即通過硬件解碼卡解碼后將圖像顯示到監(jiān)視器上。模擬顯示不能兼容多品牌的視頻圖像。

? 數(shù)字矩陣/遠(yuǎn)程控制顯示服務(wù)器播放

4.3.2設(shè)備代理／消息服務(wù)

設(shè)備代理／消息服務(wù)是前端設(shè)備與客戶端軟件通訊各類信息的樞紐，可調(diào)出各個的學(xué)校的節(jié)點，自定訂閱各個的學(xué)校所有設(shè)備的事件，并支持轉(zhuǎn)發(fā)消息。支持設(shè)備各種報警，無視頻信號報警，移動視頻報警等，IO報警，硬盤損壞，空間不足等。

? ? 與前端設(shè)備及客戶端協(xié)調(diào)工作；顯示前端設(shè)備及客戶端的各種信息，便于學(xué)校監(jiān)控人員查看； 動態(tài)ＩＰ功能；當(dāng)前端設(shè)備沒有固定IP（動態(tài)IP）時，或有靜態(tài)IP，由于某種原因無法得知，便可啟用動態(tài)IP功能。

4.3.3接/處警服務(wù)

? 接警聯(lián)動

?

接收遠(yuǎn)程報警信號，并做明顯的彈出信息提示；

? ? ? ? 接收遠(yuǎn)程報警信號后自動在中心錄像； 根據(jù)聯(lián)動策略設(shè)置控制遠(yuǎn)端報警開關(guān)輸出； 在電子地圖上明顯提示報警點發(fā)生地點； 根據(jù)聯(lián)動策略控制本地報警輸出警燈閃爍。?

4.3.4控制服務(wù)

? ?遠(yuǎn)程網(wǎng)絡(luò)開關(guān)

? 遠(yuǎn)程網(wǎng)絡(luò)開關(guān)控制: 遠(yuǎn)程控制網(wǎng)絡(luò)開關(guān)的打開和關(guān)閉；

4.3.5流媒體轉(zhuǎn)播服務(wù)

流媒體服務(wù)器模塊主要是在多級中心或分控比較多時作為減輕網(wǎng)絡(luò)負(fù)擔(dān)而用的。它主要分為兩個部分：

? 錄像檢索

當(dāng)某件事件發(fā)生時，很多部門的很多人都會同時調(diào)用同一個地方的錄像資料，那么錄像檢索緩沖模塊可在第一個人檢索時，把相應(yīng)的錄像資料保存的緩存硬盤，從第二個要檢索資料的人開始，都是從檢索緩存硬盤里面直接讀取資料，這樣大大的減緩了網(wǎng)絡(luò)的負(fù)擔(dān)

? 實時視頻轉(zhuǎn)播服務(wù)

當(dāng)多級中心或很多分控端同時監(jiān)看某路視頻時，假如上級中心或每一個分學(xué)校都去監(jiān)看某個網(wǎng)點的某路視頻時，對此網(wǎng)點的網(wǎng)絡(luò)造成了很大的負(fù)擔(dān)。通過實時視頻轉(zhuǎn)播模塊，無論多少人同時在線看一路視頻時，都由實時視頻轉(zhuǎn)播模塊去連接前端的視頻，然后分發(fā)給各個客戶端，大大的減輕了網(wǎng)絡(luò)的負(fù)擔(dān)。

4.3.6 Web服務(wù)及IE插件

WEB服務(wù)器模塊給網(wǎng)絡(luò)中其他用戶通過IE 瀏覽器訪問網(wǎng)點視頻的功能，它主要包含三個方面的內(nèi)容：

? WEB電子地圖：用戶通過瀏覽器登錄WEB服務(wù)模塊，可進(jìn)入任何一級的電子地圖，點擊電子地圖上的攝像機(jī)圖標(biāo)，可直接監(jiān)看此攝像機(jī)的網(wǎng)絡(luò)視頻圖像；

? WEB遠(yuǎn)程監(jiān)看：用戶通過瀏覽器，可用1、4、9等分屏方式來監(jiān)看遠(yuǎn)端攝像機(jī)的視頻圖像，且可在分屏上任意組合不同網(wǎng)點的不同攝像機(jī)的視頻圖像；

? WEB遠(yuǎn)程狀態(tài)：用戶通過瀏覽器，可監(jiān)看到遠(yuǎn)程DVR的狀態(tài)，包括攝像機(jī)、硬盤、CPU使用率等的狀態(tài)信息，且可進(jìn)入遠(yuǎn)程DVR的Web設(shè)置界面，對遠(yuǎn)程DVR進(jìn)行設(shè)置。

BS視頻監(jiān)控系統(tǒng)主界面

4.3.7語音廣播服務(wù)

? 支持遠(yuǎn)程實時監(jiān)聽，某路音頻可與任意一臺攝像機(jī)相連, 同步錄像和錄音，聲音與圖像數(shù)據(jù)同包； ? 主動呼叫功能，在總控制中心可任意選擇某網(wǎng)點進(jìn)行喊話或?qū)υ挘芡瑫r對16個網(wǎng)點進(jìn)行廣播講話； ? 具雙向語音對講，對講可以通過網(wǎng)絡(luò)（TCP/IP協(xié)議）或電話網(wǎng)絡(luò)（PSTN）進(jìn)行，網(wǎng)點請求對將時，相對應(yīng)的攝像機(jī)的圖像可同時彈出，以便值班人員可觀察現(xiàn)場情況； ? ? ? ? ? 中心能通過網(wǎng)絡(luò)回放任意一路視頻及音頻信號；

音質(zhì)清晰回音小，在總控制中心能自由切換其它監(jiān)控點和控制音量大小 廣播管理； 音頻轉(zhuǎn)播； 簡單視頻會議。

五、系統(tǒng)結(jié)構(gòu)設(shè)計

系統(tǒng)整體基于IVSPNET網(wǎng)絡(luò)視頻系統(tǒng)結(jié)構(gòu)，具有擴(kuò)展容易，結(jié)構(gòu)更改方便的特點。系統(tǒng)使用分層結(jié)構(gòu)，可分為二層：

接入層：各個攝像需求點實現(xiàn)所有攝像頭視頻信號的接入，將攝像頭視頻采集信號傳送到各個監(jiān)控室。傳輸方式可根據(jù)具體情況采用數(shù)字或模擬的方式，本層可以通過現(xiàn)有的DVR或者DVS對視頻監(jiān)控圖像進(jìn)行存儲。使用數(shù)模相結(jié)合的方式實現(xiàn)。

核心層：總監(jiān)控中心采用全數(shù)字監(jiān)控，各個監(jiān)控室通過網(wǎng)絡(luò)鏈路上聯(lián)到總監(jiān)控中心，實現(xiàn)全部數(shù)字信號匯聚到總監(jiān)控中心，總監(jiān)控中心實現(xiàn)重點調(diào)用以及指揮調(diào)度。

考慮校方的發(fā)展及后期工程的需要，本方案總體結(jié)構(gòu)：采用IVSPNET網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)平臺軟件，來實現(xiàn)無限擴(kuò)容要求：

各監(jiān)控點通過視頻電纜或光纖連接至監(jiān)控中心;?

各個視頻服務(wù)器和總監(jiān)控中心通過光纖進(jìn)行TCP/IP網(wǎng)絡(luò)互連;?

實現(xiàn)各個監(jiān)控室圖像對保安總監(jiān)控中心的上傳和保安總控制中心對各個視頻服務(wù)器數(shù)據(jù)的控制和調(diào)用;?

通過IVSPNET網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)平臺軟件的構(gòu)建結(jié)構(gòu)，以后的各個監(jiān)控室(分控室的攝像機(jī)不限數(shù)量)都能接入到保安總監(jiān)控中心，同時不需重復(fù)增加保安總監(jiān)控中心的控制設(shè)備。?

5．1系統(tǒng)主要技術(shù)構(gòu)成

系統(tǒng)將以“前端攝像機(jī)+視頻服務(wù)器+IVSPNET網(wǎng)絡(luò)視頻管理平臺+數(shù)字網(wǎng)絡(luò)矩陣”為核心，以IVSPNET網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)為主，對音視頻信號的傳輸、控制、切換、顯示進(jìn)行集中式控制、管理，有關(guān)領(lǐng)導(dǎo)和管理人員可通過TCP/IP網(wǎng)絡(luò)獲得相關(guān)授權(quán)并進(jìn)行分級輔控、監(jiān)看。

系統(tǒng)設(shè)計以網(wǎng)絡(luò)數(shù)字化為主，有非常好的擴(kuò)充性和對設(shè)備的兼容性，并提供相關(guān)接口，便于系統(tǒng)未來的擴(kuò)充、升級。

六、總結(jié)

基于“IVSPNET集成管理系統(tǒng)平臺”的系統(tǒng)解決方案不僅保證了銀行視頻聯(lián)網(wǎng)監(jiān)控系統(tǒng)對網(wǎng)絡(luò)資源的合理應(yīng)用，更保證了系統(tǒng)運行的可行性及可靠性，并且有效的控制了系統(tǒng)的建設(shè)成本、網(wǎng)絡(luò)建設(shè)成本及系統(tǒng)維護(hù)成本，使學(xué)校視頻聯(lián)網(wǎng)監(jiān)控系統(tǒng)真正走向成熟。