heap size setting
There are three restrictions on the maximum heap size in the JVM: the data model (32-bt or 64-bit) limit of the relevant operating system; the limit of the available virtual memory of the system; the limit of the available physical memory of the system. Under the 32-bit system, it is generally limited to 1.5G~2G; for the 64-bit operating system, there is no limit to the memory. I am testing under Windows Server 2003 system, 3.5G physical memory, JDK5.0, the maximum can be set to 1478m.
Typical setup:
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k
-Xmx3550m: Set the maximum available memory of the JVM to 3550M.
-Xms3550m: Set the JVM to cause the memory to be 3550m. This value can be set the same as -Xmx to avoid the JVM to reallocate memory every time garbage collection is done.
-Xmn2g: Set the young generation size to 2G. The entire JVM memory size = young generation size + old generation size + permanent generation size. The permanent generation generally has a fixed size of 64m, so increasing the young generation will reduce the size of the old generation. This value has a great impact on system performance, and Sun officially recommends configuring it as 3/8 of the entire heap.
-Xss128k: Set the stack size for each thread. After JDK5.0, the stack size of each thread is 1M, and the stack size of each thread was 256K before. Adjust the memory size required by more application threads. Under the same physical memory, reducing this value can generate more threads. However, the operating system still has a limit on the number of threads in a process, and it cannot be generated infinitely. The experience value is around 3000~5000.
java -Xmx3550m -Xms3550m -Xss128k -XX:NewRatio=4 -XX:SurvivorRatio=4 -XX:MaxPermSize=16m -XX:MaxTenuringThreshold=0
-XX:NewRatio=4: Set the ratio of the young generation (including Eden and two Survivor areas) to the old generation (excluding the permanent generation). If it is set to 4, the ratio of the young generation to the old generation is 1:4, and the young generation occupies 1/5 of the entire stack
-XX:SurvivorRatio=4: Set the size ratio of the Eden area to the Survivor area in the young generation. Set to 4, the ratio of two Survivor areas to one Eden area is 2:4, and one Survivor area accounts for 1/6 of the entire young generation
-XX:MaxPermSize=16m: Set the persistent generation size to 16m.
-XX:MaxTenuringThreshold=0: Set the garbage maximum age. If it is set to 0, the young generation objects will directly enter the old generation without going through the Survivor area. For applications with more old generations, efficiency can be improved. If this value is set to a larger value, the young generation object will be copied multiple times in the Survivor area, which can increase the survival time of the object in the young generation and increase the probability of being recycled in the young generation.
recycler selection
The JVM gives three options: serial collector, parallel collector, and concurrent collector, but the serial collector is only suitable for small amounts of data, so the choices here are mainly for parallel collectors and concurrent collectors. By default, JDK5.0 used to use the serial collector. If you want to use other collectors, you need to add corresponding parameters at startup. After JDK5.0, the JVM will judge based on the current system configuration.
Throughput-first parallel collector
As mentioned above, the parallel collector is mainly aimed at reaching a certain throughput, which is suitable for science and technology and background processing.
Typical configuration:
java -Xmx3800m -Xms3800m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20
-XX:+UseParallelGC: Select the garbage collector as a parallel collector. This configuration is only valid for the young generation. That is, under the above configuration, the young generation uses concurrent collection, while the old generation still uses serial collection.
-XX:ParallelGCThreads=20: Configure the number of threads of the parallel collector, that is: how many threads perform garbage collection together at the same time. This value is best configured equal to the number of processors.
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20 -XX:+UseParallelOldGC
-XX:+UseParallelOldGC: Configure the old generation garbage collection method as parallel collection. JDK6.0 supports parallel collection of the old generation.
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:MaxGCPauseMillis=100
-XX:MaxGCPauseMillis=100: Set the maximum time for each young generation garbage collection. If this time cannot be met, JVM will automatically adjust the size of the young generation to meet this value.
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:MaxGCPauseMillis=100 -XX:+UseAdaptiveSizePolicy
-XX:+UseAdaptiveSizePolicy: After setting this option, the parallel collector will automatically select the young generation area size and the corresponding Survivor area ratio to achieve the minimum response time or collection frequency specified by the target system. This value is recommended when using the parallel collector , always open.
Response Time Prioritized Concurrent Collector
As mentioned above, the concurrent collector is mainly to ensure the response time of the system and reduce the pause time during garbage collection. Applicable to application servers, telecommunications fields, etc.
Typical configuration:
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:ParallelGCThreads=20 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC
-XX:+UseConcMarkSweepGC: Set the old generation for concurrent collection. After configuring this in the test, the configuration of -XX:NewRatio=4 fails, and the reason is unknown. Therefore, at this time, the size of the young generation is best set with -Xmn.
-XX:+UseParNewGC: Set young generation for parallel collection. Can be used concurrently with CMS collection. For JDK5.0 and above, the JVM will set itself according to the system configuration, so there is no need to set this value.
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseConcMarkSweepGC -XX:CMSFullGCsBeforeCompaction=5 -XX:+UseCMSCompactAtFullCollection
-XX:CMSFullGCsBeforeCompaction: Since the concurrent collector does not compress and organize the memory space, "fragmentation" will be generated after running for a period of time, which will reduce the operating efficiency. This value sets how many times the GC is run to compress and organize the memory space.
-XX:+UseCMSCompactAtFullCollection: Turn on the compression of the old generation. May affect performance, but eliminates fragmentation
Supplementary information
JVM provides a large number of command line parameters and print information for debugging. There are mainly the following:
-XX:+PrintGC
Output format: [GC 118250K->113543K(130112K), 0.0094143 secs]
[Full GC 121376K->10414K(130112K), 0.0650971 secs]
-XX:+PrintGCDetails
Output format: [GC [DefNew: 8614K->781K(9088K), 0.0123035 secs] 118250K->113543K(130112K), 0.0124633 secs]
[GC [DefNew: 8614K->8614K(9088K), 0.0000665 secs][Tenured: 112761K->10414K(121024K), 0.0433488 secs] 121376K->10414K(130112K), 0.0436268 secs]
-XX:+PrintGCTimeStamps -XX:+PrintGC: PrintGCTimeStamps can be mixed with the above two
Output format: 11.851: [GC 98328K->93620K(130112K), 0.0082960 secs]
-XX:+PrintGCApplicationConcurrentTime: Print the uninterrupted execution time of the program before each garbage collection. Can be mixed with above
Output format: Application time: 0.5291524 seconds
-XX:+PrintGCApplicationStoppedTime: Prints the time the application was suspended during garbage collection. Can be mixed with above
Export format: Total time for which application threads were stopped: 0.0468229 seconds
-XX:PrintHeapAtGC: Print detailed stack information before and after GC