当前位置:网站首页>10: summary of JVM tuning

10: summary of JVM tuning

2021-04-11 16:42:36 Three evils

1、 Tuning principles

JVM It sounds very tall , But realize that ,JVM Tuning should be Java The last bullet in performance optimization .

Java Does the project need to be tuned

I agree with Mr. Liao Xuefeng , Realize that JVM Tuning is not a routine tool , Generally, the first choice for performance problems is to optimize the program , The final choice is to do JVM tuning .

 Tuning level

JVM The purpose of automatic memory management is to pull developers out of the mire of memory management . Even if it had to be JVM tuning , You can't adjust the parameters just by patting the forehead , We have to monitor it all , Detailed analysis of performance data .

2、JVM Time for tuning

I have to think about JVM What are the situations that are tuned ?

  • Heap Memory ( Old age ) Keep rising to the set maximum memory value ;
  • Full GC Frequent ;
  • GC The pause time is too long ( exceed 1 second );
  • Applications appear OutOfMemory Equal memory exception ;
  • The application uses local cache and takes up a lot of memory space ;
  • The system throughput and response performance are not high or decreased .

3、JVM The goal of tuning

throughput 、 Delay 、 Memory footprint is similar to the three CAP, It's an impossible triangle , Only two of them can be selected for tuning , You can't have it all .

  • Delay :GC Low pause and GC Low frequency ;
  • Low memory usage ;
  • High throughput ;

I chose two of them , It's bound to come at the expense of the other .

Here are some JVM Reference examples of quantitative objectives for tuning :

  • Heap Memory usage <= 70%;
  • Old generation Memory usage <= 70%;
  • avgpause <= 1 second ;
  • Full gc frequency 0 or avg pause interval >= 24 Hours ;

Be careful : Different applications JVM The goal of tuning quantification is different .

4、JVM The steps of tuning

In general ,JVM Tuning can be done through the following steps :

  • Analyze the operation of the system : analysis GC Journal and dump file , Decide if you need to optimize , Identify bottlenecks ;
  • determine JVM Tuning quantitative goals ;
  • determine JVM Tuning parameters ( According to history JVM Parameters to adjust );
  • Tune memory in turn 、 Delay 、 Throughput and other indicators ;
  • Compare and observe the differences before and after tuning ;
  • Constant analysis and adjustment , Until you find the right JVM Parameter configuration ;
  • Find the most suitable parameter , Apply these parameters to all servers , And follow up .

In the above operation steps , Some steps need to be completed repeatedly and iteratively . Generally, it starts from meeting the memory usage requirements of the program , Then there's the demand for time delay , Finally, the throughput requirement , To optimize based on this step , Each step is the basis for the next step , Don't go retrograde .

JVM Tuning steps

5、JVM Parameters

So let's see JDK Of JVM Parameters .

5.1、 The basic parameters

Parameter name meaning The default value is
-Xms Initial heap size In memory 1/64 Default (MinHeapFreeRatio Parameters can be adjusted ) The free heap memory is less than 40% when ,JVM It's going to pile up until -Xmx The maximum limit of .
-Xmx Maximum heap size In memory 1/4 Default (MaxHeapFreeRatio Parameters can be adjusted ) The free heap memory is larger than 70% when ,JVM It will reduce the pile until -Xms The minimum limit of
-Xmn Young generation size Be careful : The size here is (eden+ 2 survivor space). And jmap -heap Shown in New gen Is different . The whole pile size = Young generation size + Old generation size + Lasting generation size . After increasing the younger generation , It will reduce the size of the old generation . This value has a great influence on the system performance ,Sun The official recommendation is to configure the entire heap as 3/8
-XX:NewSize Set younger generation size
-XX:MaxNewSize Young generation maximum
-XX:PermSize Set persistent generation (perm gen) Initial value In memory 1/64 JDK1.8 before
-XX:MaxPermSize Set persistent generation maximum In memory 1/4 JDK1.8 before
-Xss Stack size per thread JDK5.0 After that, the stack size of each thread is 1M, Previously, the stack size of each thread was 256K. More memory size required by application thread adjustment . In the same physical memory , Reducing this value can generate more threads . But the operating system has a limit on the number of threads in a process , Can't generate... Indefinitely , Experience is in 3000~5000 about Small applications in general , If the stack is not deep , Should be 128k Sufficient It is recommended to use 256k. This option has a big impact on performance , It needs strict testing .( The headmaster ) and threadstacksize The explanation of the options is very similar , The official documents do not seem to explain , There is such a sentence in the Forum :"” -Xss is translated in a VM flag named ThreadStackSize” Generally, you can set this value .
-XX:ThreadStackSize Thread Stack Size (0 means use default stack size) [Sparc: 512; Solaris x86: 320 (was 256 prior in 5.0 and earlier); Sparc 64 bit: 1024; Linux amd64: 1024 (was 0 in 5.0 and earlier); all others 0.]
-XX:NewRatio The younger generation ( Include Eden And two Survivor District ) The ratio to the old ( Remove the permanent generation ) -XX:NewRatio=4 The ratio of young generation to old generation is 1:4, The younger generation takes up the whole stack 1/5 Xms=Xmx And set up Xmn Under the circumstances , This parameter does not need to be set .
-XX:SurvivorRatio Eden District and Survivor Area size ratio Set to 8, Two Survivor District and a Eden The ratio of regions is 2:8, One Survivor District accounts for the whole young generation 1/10
-XX:LargePageSizeInBytes The size of the memory page cannot be set too large , It will affect Perm Size =128m
-XX:+UseFastAccessorMethods Fast optimization of the original type
-XX:+DisableExplicitGC close System.gc() This parameter needs to be strictly tested
-XX:+ExplicitGCInvokesConcurrent close System.gc() disabled Enables invoking of concurrent GC by using the System.gc() request. This option is disabled by default and can be enabled only together with the -XX:+UseConcMarkSweepGC option.
-XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses close System.gc() disabled Enables invoking of concurrent GC by using the System.gc() request and unloading of classes during the concurrent GC cycle. This option is disabled by default and can be enabled only together with the -XX:+UseConcMarkSweepGC option.
-XX:MaxTenuringThreshold The maximum age of garbage If set to 0 Words , Then the young generation does not go through Survivor District , Go straight to the old generation . For the older generation more applications , Can improve efficiency . If you set this value to a larger value , The younger generation will be in Survivor Area to be copied many times , This can increase the survival of the younger generation Time , Increase the probability of being recycled in the younger generation This parameter is only in serial GC Only when effective .
-XX:+AggressiveOpts Speed up compilation
-XX:+UseBiasedLocking Lock mechanism performance improvement
-Xnoclassgc No garbage collection
-XX:SoftRefLRUPolicyMSPerMB Every megaheap of free space SoftReference Life time of 1s softly reachable objects will remain alive for some amount of time after the last time they were referenced. The default value is one second of lifetime per free megabyte in the heap
-XX:PretenureSizeThreshold How much more objects are allocated directly in the old generation 0 Unit byte The new generation adopts Parallel Scavenge GC When is invalid Another case of direct generation allocation is large array objects , And there is no external reference object in the array .
-XX:TLABWasteTargetPercent TLAB Occupy eden % of area 1%
-XX:+CollectGen0First FullGC Whether it's first or not YGC false

Jdk7 The main parameters of the version

Parameter name meaning The default value is
-XX:PermSize Set persistent generation Jdk7 Version and previous versions
-XX:MaxPermSize Set the maximum persistent generation Jdk7 Version and previous versions

Jdk8 Important unique parameters of the version

Parameter name meaning The default value is
-XX:MetaspaceSize Metaspace size Jdk8 edition
-XX:MaxMetaspaceSize The largest meta space Jdk8 edition
Parameter name meaning The default value is
-XX:+UseParallelGC Full GC use parallel MSC ( This is to be verified ) Choose garbage collector as parallel collector . This configuration is only valid for younger generation . Under the above configuration , The younger generation uses concurrent collection , The older generation still uses serial collection .( This is to be verified )
-XX:+UseParNewGC Set up the young generation to collect in parallel But with CMS Collect and use at the same time JDK5.0 above ,JVM It will be set according to the system configuration , So there's no need to set this value
-XX:ParallelGCThreads Number of threads in parallel collector This value is best configured to equal the number of processors The same applies CMS
-XX:+UseParallelOldGC Old generation garbage collection method is parallel collection (Parallel Compacting) This is JAVA 6 The parameter options that appear
-XX:MaxGCPauseMillis The longest garbage collection time of each young generation ( Maximum pause time ) If this time cannot be met ,JVM Will automatically adjust the size of the younger generation , To meet this value .
-XX:+UseAdaptiveSizePolicy Automatically select the size of the younger generation area and the corresponding Survivor Area ratio After setting this option , The parallel collector will automatically select the size of the younger generation area and the corresponding Survivor Area ratio , To achieve the minimum corresponding time or collection frequency specified by the target system , This value is recommended when using parallel collectors , Keep it open .
-XX:GCTimeRatio Set the percentage of garbage collection time in the running time of the program Formula for 1/(1+n)
-XX:+ScavengeBeforeFullGC Full GC Pre invocation YGC true Do young generation GC prior to a full GC. (Introduced in 1.4.1.)
Parameter name meaning The default value is
-XX:+UseConcMarkSweepGC Use CMS Memory collection After configuring this in the test ,-XX:NewRatio=4 The configuration of has failed , Unknown cause . therefore , At this time, the size of the younger generation is the best -Xmn Set up .???
-XX:+AggressiveHeap Trying to use a lot of physical memory Optimization of long time and large memory usage , Can check computing resources ( Memory , Number of processors ) Need at least 256MB Memory a large number of CPU/ Memory , ( stay 1.4.1 stay 4CPU There is already a lift on the )
-XX:CMSFullGCsBeforeCompaction How many times will memory compression occur Because the concurrent collector does not compress the memory space , Arrangement , So running for a while will produce " debris ", Reduce the efficiency of operation . This value sets how many times to run GC Compress the memory space later , Arrangement .
-XX:+CMSParallelRemarkEnabled Lower the mark pause
-XX+UseCMSCompactAtFullCollection stay FULL GC When , Compression of the old CMS It doesn't move memory , therefore , It's very easy to produce debris , Cause insufficient memory , therefore , Memory compression will be enabled at this time . It's a good habit to add this parameter . May affect performance , But it can eliminate debris
-XX:+UseCMSInitiatingOccupancyOnly Start with a manual definition initialization definition CMS collect prohibit hostspot Self trigger CMS GC
-XX:CMSInitiatingOccupancyFraction=70 Use cms As garbage collection Use 70% Later on CMS collect 92 In order not to appear promotion failed( See introduction below ) error , The setting of this value needs to meet the following formula CMSInitiatingOccupancyFraction Calculation formula
-XX:CMSInitiatingPermOccupancyFraction Set up Perm Gen Use the rate reached to trigger 92
-XX:+CMSIncrementalMode Set to incremental mode Used for single CPU situation
-XX:+CMSClassUnloadingEnabled

5.4、 Supporting information

Parameter name meaning The default value is
-XX:+PrintGC Output form : [GC 118250K->113543K(130112K), 0.0094143 secs] [Full GC 121376K->10414K(130112K), 0.0650971 secs]
-XX:+PrintGCDetails Output form :[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 But with -XX:+PrintGC -XX:+PrintGCDetails A mixture of Output form :11.851: [GC 98328K->93620K(130112K), 0.0082960 secs]
-XX:+PrintGCApplicationStoppedTime Time the program paused during print garbage collection . Can be mixed with the above Output form :Total time for which application threads were stopped: 0.0468229 seconds
-XX:+PrintGCApplicationConcurrentTime Print every time before garbage collection , The execution time of the program without interruption . Can be mixed with the above Output form :Application time: 0.5291524 seconds
-XX:+PrintHeapAtGC Print GC Detailed stack information before and after
-Xloggc:filename Record the relevant log information to a file for analysis . Use in combination with the above
-XX:+PrintClassHistogram garbage collects before printing the histogram.
-XX:+PrintTLAB see TLAB Use of space
XX:+PrintTenuringDistribution Check every time minor GC Threshold of new life cycle after Desired survivor size 1048576 bytes, new threshold 7 (max 15) new threshold 7 That is to say, the threshold for identifying a new life cycle is 7.

6、 Main tools

6.1、JDK Tools

JDK It comes with a lot of performance monitoring tools , We can use these tools to monitor the system and troubleshoot memory performance problems .

JDK Bring their own tools

6.2、Linux Command line tools

During performance monitoring and troubleshooting , It is often combined with the command line tools of the operating system itself .

command explain
top Real time display of the executing process CPU Usage rate 、 Memory usage and system load
vmstat Virtual memory for the operating system 、 process 、CPU Activity monitoring
pidstat Monitor the context switch of the specified process
iostat Monitoring disk IO

There are other third-party monitoring tools , It's also a powerful tool for performance analysis and troubleshooting , Such as MATGChistoJProfilerarthas.

7、 Common tuning strategies

I still want to mention , Make sure in time to JVM tuning , And don't fall into “ Knowledge and insight barrier ”, After the analysis , Find ways to improve performance by optimizing programs , The optimizer is still preferred .

7.1、 Choose the right garbage collector

CPU Single core , So there's no doubt about it Serial The garbage collector is your only choice .

CPU Multicore , Focus on throughput , So choose PS+PO Combine .

CPU Multicore , Focus on user pause time ,JDK edition 1.6 perhaps 1.7, So choose CMS.

CPU Multicore , Focus on user pause time ,JDK1.8 And above ,JVM Available memory 6G above , So choose G1.

Parameter configuration :

 // Set up Serial Garbage collector ( The new generation )
  Turn on :-XX:+UseSerialGC
 ​
 // Set up PS+PO, New generation use function Parallel Scavenge  The older generation will use Parallel Old The collector 
  Turn on  -XX:+UseParallelOldGC
 ​
 //CMS Garbage collector ( Old age )
  Turn on  -XX:+UseConcMarkSweepGC
 ​
 // Set up G1 Garbage collector 
  Turn on  -XX:+UseG1GC

7.2、 Resize memory

The phenomenon : Garbage collection is very frequent .

reason : If memory is too small , It will lead to frequent garbage collection to free up enough space to create new objects , So the effect of increasing the heap memory size is very obvious .

Be careful : If the frequency of garbage collection is very frequent , But there are very few objects that can be recycled each time , So this time is not too small memory , It may be a memory leak that causes objects not to be recycled , Thus, frequent GC.

Parameter configuration :

 // Set the initial value of the heap 
  Instructions 1:-Xms2g
  Instructions 2:-XX:InitialHeapSize=2048m
 ​
 // Set heap maximum 
  Instructions 1:`-Xmx2g` 
  Instructions 2: -XX:MaxHeapSize=2048m
 ​
 // New generation memory configuration 
  Instructions 1:-Xmn512m
  Instructions 2:-XX:MaxNewSize=512m

7.3、 Set the expected pause time

The phenomenon : The blocking of procedural Indirectness

reason : If there is no exact pause time set , The garbage collector is mainly throughput , Then the garbage collection time will be unstable .

Be careful : Don't set unrealistic pause times , The shorter the single time, the more GC The number of times to recycle the original amount of garbage .

Parameter configuration :

 //GC Pause time , The garbage collector will try to achieve this time by various means 
 -XX:MaxGCPauseMillis 

7.4、 Adjust the memory area size ratio

The phenomenon : In a certain area GC frequent , Everything else is normal .

reason : If there is not enough space in the corresponding area , Lead to the need for frequent GC To free up space , stay JVM If heap memory cannot be increased , You can adjust the size ratio of the corresponding area .

Be careful : Maybe it's not lack of space , But because of the memory leak, the memory cannot be recycled . Which leads to GC frequent .

Parameter configuration :

 //survivor Area and Eden Area size ratio 
  Instructions :-XX:SurvivorRatio=6  //S Area and Eden The ratio of area to Cenozoic is 1:6, Two S District 2:6
 ​
 // The proportion of the new generation and the old generation 
 -XX:NewRatio=4  // Represent the Cenozoic era : Old age  = 1:4  That is, the older generation takes up the whole pile of 4/5; The default value is =2

7.5、 Adjust the age of the object's aging years

The phenomenon : The older generation is more frequent GC, There are many objects to recycle each time .

reason : If they are younger , The objects of the new generation will soon enter the old generation , Leading to more objects in the old age , In fact, these objects can be recycled in a very short period of time , At this time, you can adjust the upgrade age of the object , Let the object not so easy to enter the old age, solve the old age space shortage frequently GC problem .

Be careful : After increasing the age , These objects will be in the Cenozoic for a longer time, which may lead to the Cenozoic GC The frequency increases , And copy these objects frequently GC It could be longer .

Configuration parameters :

// Into the old age, the youngest GC Age , Minimum age value of young generation object converted to old age object , The default value is 7
 -XX:InitialTenuringThreshol=7 

7.6、 Adjust the standard of large objects

The phenomenon : The older generation is more frequent GC, There are many objects to recycle each time , And the volume of a single object is relatively large .

reason : If a large number of large objects are directly allocated to the old age , It makes the old generation easy to be filled and causes frequent GC, You can set the standard for objects to enter the old age directly .

Be careful : After these large objects enter the Cenozoic, they may make the Cenozoic GC Frequency and time increase .

Configuration parameters :

 // The largest object that the new generation can accommodate , If it is greater than that, it will be distributed to the old age ,0 There is no limit to the representation .
  -XX:PretenureSizeThreshold=1000000 

7.7、 adjustment GC The trigger time of

The phenomenon :CMS,G1 often Full GC, Program stuck seriously .

reason :G1 and CMS part GC Phases are concurrent , Business threads and garbage collection threads work together , This means that the business thread will generate new objects in the process of garbage collection , So in GC You need to reserve some memory space to hold the newly generated objects , If the memory space is not enough to hold the newly generated object at this time , that JVM Will stop concurrent collection and suspend all business threads (STW) To ensure the normal operation of garbage collection . It can be adjusted at this time GC Trigger time ( For example, in the older generation 60% It triggers GC), In this way, enough space can be reserved for the objects created by the business thread to have enough space allocation .

Be careful : Trigger early GC It's going to increase the number of older people GC The frequency of .

Configuration parameters :

 // What proportion of the old age is used CMS collect , The default is 68%, If it happens frequently SerialOld Carton , It should be turned down 
 -XX:CMSInitiatingOccupancyFraction
 ​
 //G1 Set occupancy thresholds for old areas to be included in the mixed garbage collection cycle . The default occupancy rate is  65%
 -XX:G1MixedGCLiveThresholdPercent=65 

7.8、 adjustment JVM Local memory size

The phenomenon :GC The number of times 、 Time and recycled objects are normal , There's plenty of heap memory , But the newspaper OOM

reason : JVM In addition to heap memory, there is also an extra heap memory , This memory is also called local memory , However, this memory area is insufficient and will not trigger automatically GC, Only when the heap memory area is triggered will the local memory be reclaimed , Once the local memory allocation is insufficient, it will directly report OOM abnormal .

Be careful : When the local memory is abnormal, in addition to the above phenomena , The exception information may be OutOfMemoryError:Direct buffer memory. The solution is to adjust the local memory size , You can also catch when this exception occurs , Manual trigger GC(System.gc()).

Configuration parameters :

 XX:MaxDirectMemorySize

8、JVM Tuning examples

Here are some of the things that we've sorted out from the Internet JVM Tuning examples :

8.1、 After the website traffic has increased dramatically , Website response page is very slow

1、 The problem is conjecture : In the test environment, the test speed is relatively fast , But when it comes to production, it slows down , So it is speculated that the business thread may be stalled due to garbage collection .

2、 location : To confirm the correctness of the conjecture , Go online through jstat -gc Instructions notice JVM Conduct GC The frequency is very high ,GC It takes a very long time , So the basic inference is that GC The frequency is very high , So the business thread often stops , So the response of the web page is very slow .

3、 Solution : Because of the high number of page visits , So object creation is very fast , Causes the heap memory to fill easily, thus frequently GC, So the problem here is that the memory of the new generation is too small , So here you can add JVM Just memory , So initially from the original 2G Memory increased to 16G Memory .

4、 The second question is : After increasing the memory, the normal request is faster , But there's another problem , It's irregular, it's intermittently stuck , And it takes a lot longer than before to get stuck .

5、 The problem is conjecture : The practice is that the previous optimization increased the memory , So I guess it's probably because of the increase in memory , This leads to a single GC It's going to take a long time to get stuck indirectly .

6、 location : Or through jstat -gc Instructions Check out You bet FGC The number of times is not very high , But it costs FGC The time on the Internet is very high , according to GC journal See the single FGC There are dozens of seconds of time .

7、 Solution : because JVM The default is PS+PO The combination of ,PS+PO The garbage marking and collection phases are STW, So when the memory increases , It takes longer to recycle , So here we want to avoid a single GC drawn-out , So you need to replace the collector of the concurrency class , Because of the current JDK Version is 1.7, So the last choice is CMS Garbage collector , Set an expected pause time based on the previous garbage collection , After going online, the website no longer has the Caton problem .

8.2、 Caused by exporting data in the background OOM

Problem description : The company's back office system , Accidental initiation OOM abnormal , Heap memory overflow .

1、 Because it's accidental , So for the first time, I simply thought that the lack of heap memory caused , So unilaterally increased the heap memory from 4G To adjust to 8G.

2、 But the problem remains unsolved , You can only start with heap memory information , By opening -XX:+HeapDumpOnOutOfMemoryError Parameters Get heap memory dump file .

3、VisualVM Yes Pile up dump Document analysis , adopt VisualVM The object that takes up the most memory is String object , I wanted to follow String Object to find its reference , but dump The file is too large , It's always stuck when I'm tracking in , and String It takes up a lot of objects and it's normal , At the beginning, I didn't think it was the problem here , So we find the breakthrough point from the thread information .

4、 Analysis through threads , First, we found several running business threads , Then follow up the business thread one by one and look at the code , I found a way to get my attention , Export order information .

5、 Because the order information export method may have tens of thousands of data , First of all, we need to find out the order information from the database , And then generate the order information excel, This process produces a lot of String object .

6、 To test one's conjecture , So I'm ready to log in to the background to test , Results in the process of testing, it was found that the front end of the button everywhere didn't do the interactive event of graying the button after clicking , The results button can be pressed all the time , Because exporting order data is very slow , Users may find that the page doesn't respond long after clicking , It turns out that it's just a little bit , As a result, a large number of requests go into the background , Heap memory generates a lot of order objects and EXCEL object , And the method execution is very slow , As a result, these objects cannot be recycled during this period of time , So it eventually leads to a memory overflow .

7、 When you know the problem, it's easy to solve it , In the end, there was no adjustment JVM Parameters , Just add the gray status on the front-end export order button , After the back-end responds, the button can be clicked , Then we reduce the unnecessary fields to query the order information to reduce the volume of the generated object , Then the problem is solved .

8.3、 The system caused by too large single cache data CPU Soaring

1、 After the system was released, it was found that CPU All the way up to 600%, After finding this problem, the first thing to do is to locate which application is occupying CPU high , adopt top Found the corresponding one java The application to take up CPU resources 600%.

2、 If it's applied CPU Soaring , So basically, it can be positioned. It may be lock resource competition , Or frequent GC Caused by the .

3、 So I'm going to start with GC Check the situation of , If GC If normal, check from the perspective of thread , use first jstat -gc PID The instructions print out GC Information about , The result is GC Statistical information has obvious anomalies , The app has only been running for a few minutes GC It takes up a lot of time 482 second , Well, it's obviously frequent GC As a result of CPU Soaring .

4、 It's positioned to be GC The problem of , So the next step is to find frequent GC The reason why the , So we can position it in two ways , Maybe it's somewhere that creates objects frequently , Or there is a memory leak that causes the memory to be recycled .

5、 According to this idea, we decided to put the heap memory information dump Come down and have a look , Use jmap -dump The instruction takes the heap memory information dump Come down ( If the heap memory space is large, use this instruction carefully, otherwise it will affect the application , Because of our heap memory space 2G So I didn't think about it ).

6、 Put the heap memory information dump After the down , Just use visualVM Off line analysis , First, find... From the objects that use the most memory , It turns out to be the third place to see a business VO It takes up about 10% Space , Obviously there is something wrong with this object .

7、 The corresponding business code is found through the business object , Through the analysis of the code, we found a suspicious place , This business object is the object generated by viewing news information , Because I want to improve the efficiency of query , So I saved the news information to redis cache , Every time I call the information interface, I get it from the cache .

8、 Save the news to redis There is no problem with this method in cache , The problem is the news 50000 Multiple pieces of data are stored in one key Inside , As a result, every time the query news interface is called, it will start from redis Inside the handle 50000 Multiple pieces of data , And then do the screening 10 Return to the front end .50000 Multiple data means that 50000 Multiple objects , Each object 280 In bytes or so ,50000 One object has 13.3M, This means that just looking at the news once will produce at least 13.3M The object of , Then the number of concurrent requests only needs to reach 10, So it happens every second 133M The object of , And this kind of big object will be directly assigned to the old age , In that case, one 2G The size of old memory , It only takes a few seconds to fill up , triggering GC.

9、 When you know the problem, it's easy to solve it , The problem is that a single cache is too large , So just reduce the cache , Here we just need to cache the cache at the granularity of the page , Every key cache 10 As a return to the front end 1 Pages of data , In this way, every time you query news information, it will only be taken out of the cache 10 Data , To avoid this problem produce .

8.4、CPU often 100% Problem location

Problem analysis :CPU Gao must have been occupied by some program for a long time CPU resources .

1、 So we need to find out which one to occupy first CPU high .

 top   List the resource usage of each process in the system .

2、 Then find out which thread is occupied in the corresponding process CPU high .

 top -Hp  process ID    List the resources occupied by threads in the corresponding process 

3、 Find the corresponding thread ID after , Print out the stack information of the corresponding thread

printf "%x\n"  PID     Thread ID Convert to 16 Base number .
 jstack PID  Print out all thread information of the process , From the printed thread information, find the previous step converted to 16 Base thread ID The corresponding thread information .

4、 Finally, according to the stack information of the thread, locate the specific business method , Find the problem in the code logic .

 Check to see if there are threads with long time watting  or blocked
  If the thread is in watting State, ,  Focus on watting on xxxxxx, Indicates that the thread is waiting for the lock , Then find the thread holding the lock according to the address of the lock .

8.5、 High memory problem positioning

analysis : If it happens in java In progress , This is usually caused by the creation of a large number of objects , The continuous surge indicates that garbage collection can't keep up with the speed of object creation , Or memory leaks cause objects to not be recycled .

1、 First, look at garbage collection

jstat -gc PID 1000  see GC frequency , Time and other information , Print every second .
  
 jmap -histo PID | head -20    Look at the top of the heap with the largest memory footprint 20 Object types , You can initially see which object occupies the memory .

If every time GC Frequent , And the memory space recovered each time is also normal , That means that the speed of object creation leads to high memory consumption ; If you recycle very little memory at a time , Well, it's probably because of a memory leak that the memory can't be recycled all the time .

2、 Export heap memory file snapshot

jmap -dump:live,format=b,file=/home/myheapdump.hprof PID  dump Heap memory information to file .

3、 Use visualVM Yes dump Offline analysis of files , Find the object with high memory consumption , Then find the business code location where the object was created , Identify specific issues from code and business scenarios .

8.6、 Data analysis platform system is frequent Full GC

The platform is mainly for users in App Conduct regular analysis and statistics for middle behavior , And support report export , Use CMS GC Algorithm .

The data analyst finds that the system page is often stuck in use , adopt jstat Command discovery system every time Young GC After about 10% Of those who survive enter the old age .

It's because Survivor The space is too small , Every time Young GC After the survival of the object in Survivor The area won't hold , Enter the old generation ahead of time .

By increasing Survivor District , bring Survivor The area can hold Young GC Post survival objects , The object is Survivor The district has experienced many times Young GC Reaching the age threshold before entering the old age .

Every time after adjustment Young GC Only a few hundred of the surviving objects in the backward and old age run stably Kb,Full GC The frequency is greatly reduced .

8.7、 Service docking gateway OOM

Gateway mainly consumes Kafka data , Do data processing calculations and forward them to another Kafka queue , When the system runs for a few hours OOM, After a few hours of restarting the system OOM.

adopt jmap Export heap memory , stay eclipse MAT Tool analysis to find out why : In the code, some business Kafka Of topic Data is printed asynchronously , This business has a large amount of data , A lot of objects are piled up in memory waiting to be printed , Lead to OOM.

8.8、 The authentication system is frequent for a long time Full GC

The system provides various account authentication services , It is found that the system service is often unavailable when using , adopt Zabbix The monitoring platform monitoring found that the system frequently occurs in the growth time Full GC, And when triggered, the old heap memory is usually not full , It turns out that it was called in the business code System.gc().




Reference resources :

【1】: Edited by Zhou Zhiming 《 In depth understanding of Java virtual machine :JVM Advanced features and best practices 》

【2】:《 actual combat JAVA virtual machine JVM Fault diagnosis and performance optimization 》

【3】:JVM Performance tuning details

【4】: How to plan reasonably once jvm performance tuning

【5】: About GC Principles and performance tuning practices , Just read this one

【6】:Java Apply performance tuning practices

【7】:JVM actual combat :JVM Tuning strategy

【8】: General Java Project needs JVM Tuning ?

【9】:Java8 JVM Parameter interpretation

【10】:JVM Parameter setting -jdk8 Parameter setting

【11】:JVM Interview question series :JVM Configure common parameters and common GC Tuning strategy

【12】:Java1.8 Of jvm Parameter official website address

版权声明
本文为[Three evils]所创,转载请带上原文链接,感谢
https://chowdera.com/2021/04/20210411163919110j.html