tomcat內存溢出解決

建議您建立一個名爲setenv的文件。 蝙蝠和地點在Tomcat bin目錄。 與這個文件(這是由卡特琳娜。 蝙蝠和卡特琳娜。 sh腳本),您能夠更改如下Tomcat環境設置JAVA_OPTS變量:

你能夠設置最小和最大內存堆大小

JVM xms和- xmx參數 。

最好的限制取決於許多條件,如轉換,積分器ETL應該執行。 發現的信息轉換,建議最多1 GB。 例如,將最小堆大小設置爲128 MB,最大堆大小爲1024 MB,使用

JAVA_OPTS=-Xms128m -Xmx1024m

你應該設定的最大極限PermGen(永久代)內存空間大小大於默認。 默認的64 MB是不夠的企業應用程序。 一個合適的內存限制取決於不一樣的標準,但256 MB在大多數狀況下將使一個不錯的選擇。 若是PermGen空間最大過低,OutOfMemoryError:PermGen空間可能會犯錯誤。 你能夠設置JVM PermGen最大限度地使用如下參數

-XX:MaxPermSize=256m

因爲性能緣由,建議應用程序是運行在服務器模式。 Apache Tomcat不運行在默認服務器模式。 你能夠設置使用JVM - Server服務器模式參數。 你能夠設置JVM參數JAVA_OPTS變量在setenv環境變量文件。

The following is an example of a setenv.bat file:

set "JAVA_OPTS=%JAVA_OPTS% -Xms128m -Xmx1024m -XX:MaxPermSize=256m -server"

爲懶惰的讀者完整清單在這裏提供了好奇的詳細說明(下圖):

• Java < 8

-server
    -Xms<heap size>[g|m|k] -Xmx<heap size>[g|m|k]
    -XX:PermSize=<perm gen size>[g|m|k] -XX:MaxPermSize=<perm gen size>[g|m|k]
    -Xmn<young size>[g|m|k]
    -XX:SurvivorRatio=<ratio>
    -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled
    -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=<percent>
    -XX:+ScavengeBeforeFullGC -XX:+CMSScavengeBeforeRemark
    -XX:+PrintGCDateStamps -verbose:gc -XX:+PrintGCDetails -Xloggc:"<path to log>"
    -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=100M
    -Dsun.net.inetaddr.ttl=<TTL in seconds>
    -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=<path to dump>`date`.hprof
    -Djava.rmi.server.hostname=<external IP>
    -Dcom.sun.management.jmxremote.port=<port> 
    -Dcom.sun.management.jmxremote.authenticate=false 
    -Dcom.sun.management.jmxremote.ssl=false

• Java > = 8

-server
    -Xms<heap size>[g|m|k] -Xmx<heap size>[g|m|k]
    -XX:MaxMetaspaceSize=<metaspace size>[g|m|k]
    -Xmn<young size>[g|m|k]
    -XX:SurvivorRatio=<ratio>
    -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled
    -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=<percent>
    -XX:+ScavengeBeforeFullGC -XX:+CMSScavengeBeforeRemark
    -XX:+PrintGCDateStamps -verbose:gc -XX:+PrintGCDetails -Xloggc:"<path to log>"
    -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=100M
    -Dsun.net.inetaddr.ttl=<TTL in seconds>
    -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=<path to dump>`date`.hprof
    -Djava.rmi.server.hostname=<external IP>
    -Dcom.sun.management.jmxremote.port=<port> 
    -Dcom.sun.management.jmxremote.authenticate=false 
    -Dcom.sun.management.jmxremote.ssl=false

使服務器的服務器

-server

Java VM服務器應用程序特有的特性,如sofisticated JIT編譯器。 雖然這個選項是暗中支持x64虛擬機,它仍然使意義上使用它根據文檔行爲也許在將來改變。

讓你堆顯式

-Xms<heap size>[g|m|k] -Xmx<heap size>[g|m|k]

爲了不動態堆調整和滯後,這多是因爲這一點,咱們影響指定最小和最大的堆大小。 所以Java VM將花時間在全部堆只有一次提交。

-XX:PermSize=<perm gen size>[g|m|k] -XX:MaxPermSize=<perm gen size>[g|m|k]

永久代是同樣的邏輯總體堆——預約義上漿避免成本的動態變化。 不適用於Java > = 8。

-XX:MaxMetaspaceSize=<metaspace size>[g|m|k]

默認Metaspace Java VM 8不是有限的,但爲了系統的穩定性是有意義的限制一些有限的價值。

-Xmn<young size>[g|m|k]

影響年輕一代的定義大小。

-XX:SurvivorRatio=<ratio>

比決定survivour空間相對伊甸園的大小尺寸。 比率能夠計算使用如下公式:

倖存者比率  =  年輕的大小  倖存者大小  −  2 

瞭解更多 和 這個太 。

使GC對吧

-XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled

做爲服務器應用程序的響應時間是相當重要的併發收集器英尺適合Web應用程序。 annihilate G1還不生產準備好了,所以咱們不得不使用併發標記-清除收集器。

-XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=<percent>

默認狀況下CMS GC使用啓發式規則觸發垃圾回收。 這使GC難以預測,一般傾向於收集延遲到年老代幾乎佔領了。 啓動它事先容許舊一代充滿前完成收集,從而避免完整GC(即中止一切暫停)。 - xx:+ UseCMSInitiatingOccupancyOnly 防止使用GC啓發式。- xx:CMSInitiatingOccupancyFraction 告訴Java VM當CMS應該觸發。 基本上,它容許在堆中建立一個緩衝區,能夠填滿數據,而CMS是有效的。 所以應該從新計算百分比從內存消耗的速度在老一輩生產負荷。 這些百分比應該仔細選擇,若是這將是小- CMS將常常工做,若是這將是大- CMS會太晚,觸發 併發模式失敗 可能發生。 一般- xx:CMSInitiatingOccupancyFraction 應該在70級,這意味着應用程序應該使用更少,70%的老的一代。

-XX:+ScavengeBeforeFullGC -XX:+CMSScavengeBeforeRemark

指導年輕一代垃圾收集器收集以前作完整GC或CMS備註階段和結果improvde因爲沒有須要檢查他們的表現年輕一代之間的引用和終身。

瞭解更多 和 一些新鮮的 。

GC日誌記錄

-XX:+PrintGCDateStamps -verbose:gc -XX:+PrintGCDetails -Xloggc:"<path to log>"

這些選項讓Java垃圾收集器記錄活動到指定的文件中。 全部記錄將前綴與人類可讀的日期和時間。 與此同時,你應該避免使用 - xx:+ PrintGCTimeStamps 由於它會預謀和無用的時間戳記錄以來Java應用程序開始。

生成日誌能夠稍後分析 GCViewer 。

-XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=100M

GC日誌文件旋轉使垃圾收集問題的分析更容易,也保證磁盤免受過分消費空間。

瞭解更多 和 多一點 。

DNS緩存

-Dsun.net.inetaddr.ttl=<TTL in seconds>

的秒數在此期間將在Java VM緩存DNS記錄。 違約行爲的Java VM 6永遠是緩存,不腳服務器應用程序的需求,當你不想每次從新啓動服務器,當IP改變了DNS記錄。 它已經改變了在Java VM 7緩存30秒鐘,但前提是安全管理器沒有安裝。 根據版本的Java VM和存在的安全管理器緩存DNS記錄還能夠無限。 
一般推薦的選項是禁用DNS緩存,能夠性能降低的緣由。 請求DNS synchorized塊執行,僅執行一個請求在任什麼時候間點。 所以,若是您的應用程序是havily利用網絡將經歷飽和DNS請求,因此TTL值 0 應該 歷來沒有 被使用。

更好的解決方案是爲合理的緩存不長時間,例如1分鐘( 60 秒)。 這意味着您的應用程序交互系統必須保證兩個不一樣的ip將繼續正常工做在這1分鐘,不然下降TTL值應該選擇。 這應該是合理的(不等於 0 ),以防止可能的爭用請求DNS。

這個選項是方便使用,可是 networkaddress.cache.ttl 中指定% % JRE / lib / security / java。 安全應該被認爲是更好的解決方案,至少從官方文檔潛在。

瞭解更多 。

內存轉儲

-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=<path to dump>`date`.hprof

若是您的應用程序會失敗在生產內存不足,你不想等待另外一個機會來重現該問題。 這些選項指示Java VM內存轉儲到文件,當伯父發生。 它可能致使至關大的停頓大伯父活動期間堆。 然而,若是Java VM是伯父,收集儘量多的信息關於這個問題比努力更重要交通徹底破碎的應用程序服務。 咱們也確保轉儲將使用名稱建立獨特的每一個應用程序啓動時間(這是requeired由於Java VM將沒法覆蓋現有的文件)。

瞭解更多 。

讓JMX的工做

-Djava.rmi.server.hostname=<external IP>

IP地址,這將是嵌入到RMI存根發給客戶。 後來客戶將使用這個存根經過RMI與服務器通訊。 在現代數據中心機一般有兩個IPs(內部和外部)你想要顯式地指定使用哪一個IP,不然JVM將使它本身的選擇。 正確的該屬性值使用JMX是成功的先決條件。

-Dcom.sun.management.jmxremote.port=<port> 
-Dcom.sun.management.jmxremote.authenticate=false 
-Dcom.sun.management.jmxremote.ssl=false

-Dcom.sun.management.jmxremote 選項不須要從Java VM 6開始,然而讓JMX可用於遠程訪問特定聽應提供港口。 後來這個端口可使用任何JMX工具(如用於鏈接。 VisualVM 或 Java任務控制 )。

還減小額外的麻煩與鏈接禁用標準認證,但確保只有通過受權的用戶可使用防火牆鏈接到環境。 若是出於安全考慮,你仍是想控制經過標準的訪問機制 瞭解更多 。

注:

許多選項之前很是有用的更新在Java VM(特別是發佈Java 7)默認預配置:

• - xx:+ UseCompressedOops
• -Dsun.rmi.dgc.server。 gcInterval = 3600000和-Dsun.rmi.dgc.client.gcInterval = 3600000
• -Dcom.sun.management.jmxremote