meminfo jvm 相關設置

cat /proc/meminfo 讀出的內核信息進行解釋：
MemTotal: 507480 kB
MemFree: 10800 kB
Buffers: 34728 kB
Cached: 98852 kB
SwapCached: 128 kB
Active: 304248 kB
Inactive: 46192 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 507480 kB
LowFree: 10800 kB
SwapTotal: 979956 kB
SwapFree: 941296 kB
Dirty: 32 kB
Writeback: 0 kB
AnonPages: 216756 kB
Mapped: 77560 kB
Slab: 22952 kB
SReclaimable: 15512 kB
SUnreclaim: 7440 kB
PageTables: 2640 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
CommitLimit: 1233696 kB
Committed_AS: 828508 kB
VmallocTotal: 516088 kB
VmallocUsed: 5032 kB
VmallocChunk: 510580 kB

MemTotal: 所有可用RAM大小（即物理內存減去一些預留位和內核的二進制代碼大小）

MemFree: LowFree與HighFree的總和，被系統留着未使用的內存

Buffers: 用來給文件做緩衝大小

Cached: 被高速緩衝存儲器（cache memory）用的內存的大小（等於 diskcache minus SwapCache ）.

SwapCached:被高速緩衝存儲器（cache memory）用的交換空間的大小
已經被交換出來的內存，但仍然被存放在swapfile中。用來在需要的時候很快的被替換而不需要再次打開I/O端口。

Active: 在活躍使用中的緩衝或高速緩衝存儲器頁面文件的大小，除非非常必要否則不會被移作他用.

Inactive: 在不經常使用中的緩衝或高速緩衝存儲器頁面文件的大小，可能被用於其他途徑.

HighTotal:
HighFree: 該區域不是直接映射到內核空間。內核必須使用不同的手法使用該段內存。

LowTotal:
LowFree: 低位可以達到高位內存一樣的作用，而且它還能夠被內核用來記錄一些自己的數據結構。Among many
other things, it is where everything from the Slab is
allocated. Bad things happen when you're out of lowmem.

SwapTotal: 交換空間的總大小

SwapFree: 未被使用交換空間的大小

Dirty: 等待被寫回到磁盤的內存大小。

Writeback: 正在被寫回到磁盤的內存大小。

AnonPages：未映射頁的內存大小

Mapped: 設備和文件等映射的大小。

Slab: 內核數據結構緩存的大小，可以減少申請和釋放內存帶來的消耗。

SReclaimable:可收回Slab的大小

SUnreclaim：不可收回Slab的大小（SUnreclaim+SReclaimable＝Slab）

PageTables：管理內存分頁頁面的索引表的大小。

NFS_Unstable:不穩定頁表的大小
VmallocTotal: 可以vmalloc虛擬內存大小

VmallocUsed: 已經被使用的虛擬內存大小。

VmallocChunk: largest contigious block of vmalloc area which is free


PermGen space的全稱是Permanent Generation space,是指內存的永久保存區域OutOfMemoryError: PermGen space從表面上看就是內存益出，解決方法也一定是加大內存。說說爲什麼會內存益出：這一部分用於存放Class和Meta的信息,Class在被 Load的時候被放入PermGen space區域，它和和存放Instance的Heap區域不同,GC(Garbage Collection)不會在主程序運行期對PermGen space進行清理，所以如果你的APP會LOAD很多CLASS的話,就很可能出現PermGen space錯誤。這種錯誤常見在web服務器對JSP進行pre compile的時候。 如果你的WEB APP下都用了大量的第三方jar, 其大小 超過了jvm默認的大小(4M)那麼就會產生此錯誤信息了。
解決方法： 手動設置MaxPermSize大小
改正方法：-Xms256m -Xmx256m -XX:MaxNewSize=256m -XX:MaxPermSize=256m


修改TOMCAT_HOME/bin/catalina.sh
JAVA_OPTS="-server -XX:PermSize=64M -XX:MaxPermSize=128m
建議：將相同的第三方jar文件移置到tomcat/shared/lib目錄下，這樣可以達到減少jar 文檔重複佔用內存的目的。


Sun文檔是這樣解釋的：

java.lang.OutOfMemoryError: PermGen space

The detail message PermGen space indicates that the permanent generation is full. The permanent generation is the area of the heap where class and method objects are stored. If an application loads a very large number of classes, then the size of the permanent generation might need to be increased using the -XX:MaxPermSize option.

Interned java.lang.String objects are also stored in the permanent generation. The java.lang.String class maintains a pool of strings. When the intern method is invoked, the method checks the pool to see if an equal string is already in the pool. If there is, then the intern method returns it; otherwise it adds the string to the pool. In more precise terms, the java.lang.String.intern method is used to obtain the canonical representation of the string; the result is a reference to the same class instance that would be returned if that string appeared as a literal. If an application interns a huge number of strings, the permanent generation might need to be increased from its default setting.

When this kind of error occurs, the text String.intern or ClassLoader.defineClass might appear near the top of the stack trace that is printed.

The jmap -permgen command prints statistics for the objects in the permanent generation, including information about internalized String instances. See 2.6.4 Getting Information on the Permanent Generation.

下面是某人遇到的問題：

SUN JDK+Tomcat 5.5.20運行服務的時候遇到問題，服務器跑幾天後就會掛掉，並報java.lang.OutOfMemoryError: PermGen space異常。

發現很多人把問題歸因於： spring,hibernate,tomcat，因爲他們動態產生類,導致JVM中的permanent heap溢出 。然後解決方法衆說紛紜，有人說升級 tomcat版本到最新甚至乾脆不用tomcat。還有人懷疑spring的問題，在spring論壇上討論很激烈，因爲spring在AOP時使用CBLIB會動態產生很多類。

但問題是爲什麼這些王牌的開源會出現同一個問題呢，那麼是不是更基礎的原因呢？tomcat在Q&A很隱晦的回答了這一點。（Why does the memory usage increase when I redeploy a web application? Because the Classloader (and the Class objects it loaded) cannot be recycled. They are stored in the permanent heap generation by the JVM, and when you redepoy a new class loader is created, which loads another copy of all these classes. This can cause OufOfMemoryErrors eventually. ）

於是有人對更基礎的JVM做了檢查，發現了問題的關鍵。原來SUN 的JVM把內存分了不同的區，其中一個就是permanent區用來存放用得非常多的類和類描述。本來SUN設計的時候認爲這個區域在JVM啓動的時候就固定了，但他沒有想到現在動態會用得這麼廣泛。而且這個區域有特殊的垃圾收回機制，現在的問題是動態加載類到這個區域後，gc根本沒辦法回收！

對這個bug最徹底的解決辦法就是不要用SUN的JDK，而改用BEA的 JRokit.


在tomcat中redeploy時出現outofmemory的錯誤.

可以有以下幾個方面的原因:

１,使用了proxool,因爲proxool內部包含了一個老版本的cglib.

2, log4j,最好不用,只用common-logging

3, 老版本的cglib,快點更新到最新版。

４，更新到最新的hibernate3.2
3、 這裏以tomcat環境爲例，其它WEB服務器如jboss,weblogic等是同一個道理。


二、java.lang.OutOfMemoryError: Java heap space
Heap size 設置
JVM堆的設置是指java程序運行過程中JVM可以調配使用的內存空間的設置.JVM在啓動的時候會自動設置Heap size的值，
其初始空間(即-Xms)是物理內存的1/64，最大空間(-Xmx)是物理內存的1/4。可以利用JVM提供的-Xmn -Xms -Xmx等選項可
進行設置。Heap size 的大小是Young Generation 和Tenured Generaion 之和。
提示：在JVM中如果98％的時間是用於GC且可用的Heap size 不足2％的時候將拋出此異常信息。
提示：Heap Size 最大不要超過可用物理內存的80％，一般的要將-Xms和-Xmx選項設置爲相同，而-Xmn爲1/4的-Xmx值。
解決方法：手動設置Heap size
修改TOMCAT_HOME/bin/catalina.sh
在“echo "Using CATALINA_BASE: $CATALINA_BASE"”上面加入以下行：
JAVA_OPTS="-server -Xms800m -Xmx800m -XX:MaxNewSize=256m"

三、實例，以下給出1G內存環境下java jvm 的參數設置參考：

JAVA_OPTS="-server -Xms800m -Xmx800m -XX:PermSize=64M -XX:MaxNewSize=256m -XX:MaxPermSize=128m -Djava.awt.headless=true "


針對Tomcat，如果Tomcat下面有多個應用，儘可能的把lib下共用的jar文件放到Tomcat的lib下，發佈速度和運行速度上也有所提升。


題外話：經常看到網友抱怨tomcat的性能不如...，不穩定等，其實根據筆者幾年的經驗，從"互聯星空“到現在的房產門戶網，我們 均使用tomcat作爲WEB服務器，每天訪問量百萬多，tomcat仍然運行良好。建議大家有問題多從自己程序入手，多看看java的DOC文檔。

參考文檔：http://blogs.sun.com/jonthecollector/entry/presenting_the_permanent_generation


文章出處：http://blog.csdn.net/xiaojianpitt/archive/2008/11/11/3276790.aspx


本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/chen1255/archive/2009/12/26/5082939.aspx