Transfer: https://blog.csdn.net/qq_3761… Load balancing architecture configuration

In the early projects, the problems are mainly in the code layer. The most easy problems in the code layer are deadlock, heap memory overflow, or setting too small to judge the heap overflow. There are two general solutions:

  • 1. The contrast

    You can compare a file with a file after the run to see if there is an increase
  • 2. Set outofMemory, if any, to this file

JVM/GC analysis and tuning

JVM Other than the heap, what are our purposes for using the JVM? It’s Tomcat. When we analyze the JVM, we analyze Tomcat. Tomcat has two levels:

  • 1. Tomcat’s own Settings:

  • 2.jvm

    1. Heap, memory Settings 2. Thread deadlocks 3

This time we will talk about:Setup for GC and Tomcat itself, plus nginx before Tomcat

Manually perform garbage collection.

The general code does not appear the problem of the dozen, is not the need to tune GC. The usual way to look at code problems is through GC phenomena. It can be used for temporary optimization

GC is divided into two parts:YoungGC and fullGC

Young GC: Recycle Young GC

Full GC: Recycle the aged ones

If we compare objects to people, they also have a life cycle

Early childhood (Young GC)-- > Young state (S0,S1 survival zone, survival zone)-- > old age Early childhood: the most likely to die out, this period will occur frequently Young GC. S0,S1, S0,S1, S0,S1, S0,S1, S0,S1, S0,S1 The slowest to recycle

If the RESOURCES of the JVM are given to the GC, the business requests will not be processed

The heap overflow is because the object is being generated all the time, living all the time, the heap is in the old area, the object is being generated faster than GC. More and more, it’ll overflow

If the fullGC is too large, a SINGLE GC will take too much time. If it’s too small, it’s too often. If the code is good, bad to oldGC. Under youngGC it is cleared. This is because the JVM’s resources are not processed by the GC

jmap -heap 23816

Jstat -gc 23816 1000 5 (1000:5 milliseconds)

S0C: S0 region capacity (S1 is the same, omitted) S0U: S0 region capacity Used EC: E region capacity EU: E region capacity used OC: Old age capacity OU: Old age capacity USED PC: Perm capacity PU: Perm region capacity used YGC: Number of Young GC (Minor GC) YGCT: Young GC Total time FGC: Full GC number FGCT: Full GC total time GCT: total GC time

Notes:

Jvm heap size = young generation + old generation Young generation = Young generation -1+S0+S1 Note that young generation -1, S0, S1 are actually dynamically adjusted, the sum is basically young generation Java blocking threading model can be abandoned, mature NIO framework is more. The problem with blocking IO is that the number of threads grows linearly, whereas NIO can be converted to constant threads. Therefore, NIO is a good choice for server-side applications

This is not to say that GC is fine-tuned, but that the code is not tuned normally

Memory overflow is at the system level (swap, si, so). Preferably 0) Heap overflow is usually process level (tomcat)

There are three things that we use:

3. The implementation strategy of the old area (for example, when 80% of the old area reaches oldGC) 4. The GC algorithm (generally do not want us to change)

1. GC tuning principles:

Most Java applications do not need GC tuning. Most of them need GC tuning. It is not a parameter problem, it is a code problem. Analyzing GC conditions optimizes code much more than optimizing GC parameters; GC tuning is a last resort

2. GC tuning purpose:

The GC time is small enough. The number of GCS occurs infrequently enough. Full The GC cycle is long enough and the time is reasonable. Index range:
Note: GC is not required if the following parameters are met: Minor takes less than 50ms to execute a GC. Minor Indicates that the GC is executed infrequently, about once every 10 seconds. Full The GC execution time is less than 1s. Full The FREQUENCY of GC execution is not less than 10 minutes.

3. Special Note:

It is recommended that the heap memory of the JVM in the multi-user store be no less than 1024 MB. The maximum memory of the JVM does not exceed 80% of the server memory resources

4, JVM performance scenario analysis case

1, the machine is abnormal: Java. Lang. OutOfMemoryError: GC overhead limit exceeded the exception: GC to release small space but spent too much time, generally there are two reason: 1, the heap is too small, 2, and there are infinite loop or large objects;

2, a service system, often appear lag, analysis of the reason, found that Full GC time is too long: (Young GC is generally 30-60ms, and oldGC is less than 1 second) It is found that Young GC is executed 54 times, and the time is 2.047 seconds, each time Young GC takes 37ms, which is in the normal range, while Full GC is executed 5 times, and the time is 6.946 seconds, and the average time is 1.389s. According to the data, the problem of Full GC takes a long time. The analysis of this system refers to the discovery that NewRatio=9, that is to say, the size ratio of Cenozoic generation and old generation is 1:9. This is the reason of the problem: 1. 2. The old age is large, so it takes a long time to carry out Full GC; The optimization method is to adjust the value of NewRatio to 4. It is found that the Full GC does not occur again and only the Young GC is executing. This is to control the objects in the new generation to clean up, not into the old age

5, the JVM common error cause summary:

1, the old generation heap filled exception: ` Java. Lang. OutOfMemoryError: Java heap space ` filled exception: 2, lasting generation ` Java. Lang. OutOfMemoryError: PermGen space ` # # # # : Perm air filled between 3, stack overflow exception: ` Java. Lang. StackOverflowError ` # # # # : This is not much said, it is commonly recursive didn't return, or cycle call: 4, system memory occupied full conditions caused by ` Java. Lang. OutOfMemoryError: unable to create new native thread` com.mysql.jdbc.util.ReadAheadInputStream.fill()