GC Out of memory Error: GC overhead limit exceeded
7312 ワード
Problem
In the T/D project , I occurred a problem that "Out of memory Error: GC overhead limit exceeded", when I request data on the browser.
Out of memory Error:GC overhead limit exceededはOOMを予測し、アプリケーションが停止する前に現場保存データを保存するなどの最後のあがきをする.
Create gc.log
Firstly, I need read the gabage collection (GC) log file.But where is it?
We use the eclipse. right-click the java project , choose properties --> Run/Debug Settings --> run_7thonline --> Edit.. If there is not application, we can new an application, then edit it.
in the VM arguments we can config the VM includes GC like that:
Now we run the project , we can find the GCLOG.log at E:GCLOG.log.
We can see these data in the file.
GCとFull GCはgcの停止タイプを表し、Full GCはstop-the-worldを表す.矢印の両側はgc前後の領域空間の大きさで、それぞれyoung領域、tenured領域、perm領域で、括弧の中でこの領域の総大きさです.コロンの前はgcが発生した時間で、単位は秒で、jvm起動から計算を開始します.DefNewはSerialコレクターを表し、Default New Generationの略であり、同様にPSYoungGen、Parallel Scavengeコレクターを表す.これにより、GC overhead limit exceededの原因を解析ログで見つけ、対応するパラメータを調整することで問題を解決できます.
root cause
ここでは、大きなメモリを使用するコードやデッドサイクルがあるかどうかを確認します.
The parameter configuration of GC
Where can we find the parameter information of GC?
http://docs.oracle.com/cd/E22289_01/html/821-1274/configuring-the-default-jvm-and-java-arguments.html
Configuring JVM Options
The following table summarizes the Java options that can have an impact onserver performance. Note that some of these options apply only to theSun JVM.
Condition
Option
Description
-server
Selects server application runtime optimizations. The directory server will take longer to startand “warm up” but will be more aggressively optimized to produce higher throughput.
-d64
For64-bit machines only. By default, the directory server selects a 32-bit JVM regardlessof the architecture. This options should be specified when a large JVM heapis required (greater than 4 Gytes) and the architecture is 64-bit.
-Xms2G -Xmx2G
Selects the initialand maximum memory sizes available to the JVM, respectively. These values are usedfor the JVM heap, which reserves memory for the directory server and itsdatabase (DB) cache (or caches if more than one). Increasing the amount ofmemory available can improve performance, but increasing it to too high a valuecan have a detrimental effect in the form of longer pauses for fullgarbage collection runs. Therefore, the initial and maximum sizes should be set tothe same value. As a general guideline, take a look atthe size of the Oracle Berkeley Java Edition (JE) database folders (
instance-dir/OUD/db/userRoot). Basedon the folders' combined size, determine how much memory you want to reservefor the DB cache. After determining this value, tune the local DB back-endproperties,
db-cache-percent or
db-cache-size and other JVM options appropriately. Be careful to allowadditional memory for the server runtime. For example, if you have a singledatabase of 1 Gbyte, which you want to store entirely in memory, thena 2 Gbyte heap with 60% reserved for the DB cache shouldbe sufficient for efficient directory server performance. You can test this setup by preloadingthe database with the local database back end by using the
preload-time-limitproperty.
JVM heaps greater than 4 Gbytes require a 64-bit JVM.
DisableExplicitGC
Prevents externalapplications from forcing expensive garbage collections. If you are using
jstatd or otherRMI-based applications to monitor Oracle Unified Directory, you should consider using this optionin order to avoid unexpected pauses.
-XX:NewSize=512M
In heavy throughput environments, you should consider usingthis option to increase the size of the JVM young generation. By default,the young generation is quite small, and high throughput scenarios can result ina large amount of generated garbage. This garbage collection, in turn, causes theJVM to inadvertently promote short-lived objects into the old generation.
Server Only
-XX:+UseConcMarkSweepGC
Selects the CMSgarbage collector. This garbage collector is set for
low pause time. It will resultin a Java application that has a lower average throughput, but much shorterCPU-intensive garbage collections. This option is required in environments that have response timeconstraints.
-XX:CMSInitiatingOccupancyFraction=70
Selects the level at which the collection is started. The default value is68%.
Offline Import Only
-XX:+UseParallelOldGC
Selects the parallel old generational garbage collector. This garbage collectoris set for
high throughput. It will maximize the average throughput of the
import-ldifutility at the cost of an occasional stop-the-world garbage collection, which is notas critical to imports.
-XX:+PrintGCDetails
Prints the garbage collection details.
-XX:+PrintGCTimeStamps
Prints the garbage collection time stampsto help with debugging.
Other Applications (for example,
dsconfig)
-client
Selects client application run-time optimizations.The application will be faster to start and more responsive due to lowercompilation overheads.
-Xms8m
Selects a low initial JVM heap size for an application.
Refer to
http://www.cnblogs.com/hucn/p/3572384.html#undefined
http://docs.oracle.com/cd/E22289_01/html/821-1274/configuring-the-default-jvm-and-java-arguments.html
http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html
In the T/D project , I occurred a problem that "Out of memory Error: GC overhead limit exceeded", when I request data on the browser.
Out of memory Error:GC overhead limit exceededはOOMを予測し、アプリケーションが停止する前に現場保存データを保存するなどの最後のあがきをする.
Create gc.log
Firstly, I need read the gabage collection (GC) log file.But where is it?
We use the eclipse. right-click the java project , choose properties --> Run/Debug Settings --> run_7thonline --> Edit.. If there is not application, we can new an application, then edit it.
in the VM arguments we can config the VM includes GC like that:
-Dcatalina.home="D:\Tomcat6.0"
-Dcatalina.base="D:\Tomcat6.0"
-Djava.io.tmpdir="D:\Tomcat6.0\temp"
-XX:-UseGCOverheadLimit
-Xmx1024m -Xms564m
-XX:+PrintGCDetails -Xloggc:E:GCLOG.log
-Dfile.encoding=UTF-8
-Dsystem.rootLocation=E:\7thOnline\
-DefsnPackage.EfsnClass.languageLocale=en_US
-DefsnPackage.EfsnClass.sendEmail=false
-DefsnPackage.EfsnClass.cachePages=false
-DefsnPackage.EfsnClass.reportReplaceError=true
-DefsnPackage.EfsnClass.hideLanguageTag=trueNow we run the project , we can find the GCLOG.log at E:GCLOG.log.
We can see these data in the file.
1434.182: [Full GC [PSYoungGen: 170752K->18288K(339200K)] [PSOldGen: 1023999K->1023999K(1024000K)] 1194751K->1042288K(1363200K) [PSPermGen: 57173K->57173K(57472K)], 2.1048891 secs] [Times: user=2.09 sys=0.00, real=2.11 secs]
1437.589: [Full GC [PSYoungGen: 170752K->22251K(339200K)] [PSOldGen: 1023999K->1023999K(1024000K)] 1194751K->1046251K(1363200K) [PSPermGen: 57173K->57173K(57472K)], 2.0801601 secs] [Times: user=2.06 sys=0.00, real=2.08 secs]
1441.242: [Full GC [PSYoungGen: 170752K->0K(339200K)] [PSOldGen: 1023999K->1020329K(1024000K)] 1194751K->1020329K(1363200K) [PSPermGen: 57173K->57173K(57472K)], 2.5077113 secs] [Times: user=2.51 sys=0.00, real=2.51 secs]
1445.061: [Full GC [PSYoungGen: 170752K->407K(339200K)] [PSOldGen: 1020329K->1023999K(1024000K)] 1191081K->1024407K(1363200K) [PSPermGen: 57173K->57173K(57472K)], 2.0983663 secs] [Times: user=2.09 sys=0.00, real=2.10 secs]
1448.933: [Full GC [PSYoungGen: 170752K->12820K(339200K)] [PSOldGen: 1023999K->1023999K(1024000K)] 1194751K->1036820K(1363200K) [PSPermGen: 57173K->57173K(57472K)], 2.1792817 secs]GCとFull GCはgcの停止タイプを表し、Full GCはstop-the-worldを表す.矢印の両側はgc前後の領域空間の大きさで、それぞれyoung領域、tenured領域、perm領域で、括弧の中でこの領域の総大きさです.コロンの前はgcが発生した時間で、単位は秒で、jvm起動から計算を開始します.DefNewはSerialコレクターを表し、Default New Generationの略であり、同様にPSYoungGen、Parallel Scavengeコレクターを表す.これにより、GC overhead limit exceededの原因を解析ログで見つけ、対応するパラメータを調整することで問題を解決できます.
root cause
ここでは、大きなメモリを使用するコードやデッドサイクルがあるかどうかを確認します.
The parameter configuration of GC
Where can we find the parameter information of GC?
http://docs.oracle.com/cd/E22289_01/html/821-1274/configuring-the-default-jvm-and-java-arguments.html
Configuring JVM Options
The following table summarizes the Java options that can have an impact onserver performance. Note that some of these options apply only to theSun JVM.
Condition
Option
Description
-server
Selects server application runtime optimizations. The directory server will take longer to startand “warm up” but will be more aggressively optimized to produce higher throughput.
-d64
For64-bit machines only. By default, the directory server selects a 32-bit JVM regardlessof the architecture. This options should be specified when a large JVM heapis required (greater than 4 Gytes) and the architecture is 64-bit.
-Xms2G -Xmx2G
Selects the initialand maximum memory sizes available to the JVM, respectively. These values are usedfor the JVM heap, which reserves memory for the directory server and itsdatabase (DB) cache (or caches if more than one). Increasing the amount ofmemory available can improve performance, but increasing it to too high a valuecan have a detrimental effect in the form of longer pauses for fullgarbage collection runs. Therefore, the initial and maximum sizes should be set tothe same value. As a general guideline, take a look atthe size of the Oracle Berkeley Java Edition (JE) database folders (
instance-dir/OUD/db/userRoot). Basedon the folders' combined size, determine how much memory you want to reservefor the DB cache. After determining this value, tune the local DB back-endproperties,
db-cache-percent or
db-cache-size and other JVM options appropriately. Be careful to allowadditional memory for the server runtime. For example, if you have a singledatabase of 1 Gbyte, which you want to store entirely in memory, thena 2 Gbyte heap with 60% reserved for the DB cache shouldbe sufficient for efficient directory server performance. You can test this setup by preloadingthe database with the local database back end by using the
preload-time-limitproperty.
JVM heaps greater than 4 Gbytes require a 64-bit JVM.
DisableExplicitGC
Prevents externalapplications from forcing expensive garbage collections. If you are using
jstatd or otherRMI-based applications to monitor Oracle Unified Directory, you should consider using this optionin order to avoid unexpected pauses.
-XX:NewSize=512M
In heavy throughput environments, you should consider usingthis option to increase the size of the JVM young generation. By default,the young generation is quite small, and high throughput scenarios can result ina large amount of generated garbage. This garbage collection, in turn, causes theJVM to inadvertently promote short-lived objects into the old generation.
Server Only
-XX:+UseConcMarkSweepGC
Selects the CMSgarbage collector. This garbage collector is set for
low pause time. It will resultin a Java application that has a lower average throughput, but much shorterCPU-intensive garbage collections. This option is required in environments that have response timeconstraints.
-XX:CMSInitiatingOccupancyFraction=70
Selects the level at which the collection is started. The default value is68%.
Offline Import Only
-XX:+UseParallelOldGC
Selects the parallel old generational garbage collector. This garbage collectoris set for
high throughput. It will maximize the average throughput of the
import-ldifutility at the cost of an occasional stop-the-world garbage collection, which is notas critical to imports.
-XX:+PrintGCDetails
Prints the garbage collection details.
-XX:+PrintGCTimeStamps
Prints the garbage collection time stampsto help with debugging.
Other Applications (for example,
dsconfig)
-client
Selects client application run-time optimizations.The application will be faster to start and more responsive due to lowercompilation overheads.
-Xms8m
Selects a low initial JVM heap size for an application.
Refer to
http://www.cnblogs.com/hucn/p/3572384.html#undefined
http://docs.oracle.com/cd/E22289_01/html/821-1274/configuring-the-default-jvm-and-java-arguments.html
http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html