I heard that wechat search “Java fish” will change strong oh!

This article is posted on Github and Gitee, and contains my entire Java series of articles for study and interview purposes

(1) Overview

The delicate design of parameters for the JVM has been an incidental issue for most development, whether it’s copying a set of parameters online or using parameters from other applications in the company. But this haphazard manoeuvre may leave problems for the future. Allocating too much memory to the JVM is fine, wasting resources, but allocating too little memory can lead to frequent Full GC, giving the impression that the system is stuck. This article examines how to set JVM vm parameters in combination with scenarios through an example.

Of course, the more important part of this article is to give you a better understanding of what’s going on inside the virtual machine by estimating parameters. For the most accurate parameter Settings, it’s useful to have tools that record the changes in various areas of the JVM.

(2) Pre-preparation

The system is based on JDK1.8, and the heap structure is as follows.

In order to facilitate the understanding of business, this paper takes the transaction system of e-commerce as an example. Under the micro-service architecture, the mainstream Internet companies will split their business into multiple service architectures. For example, the e-commerce system will be divided into transaction micro-service, shopping cart micro-service, commodity micro-service, etc. The granularity may be finer. An underlying architecture integrates these microservices. It’s basically a big container with jar packages in it.

(3) The estimation process in common business scenarios

A transaction micro-service will involve a series of objects such as order objects, coupon objects, user objects and transaction record objects. We can simply estimate the space occupied by these objects in a transaction. The way to estimate the size is also very simple. The eight basic types are inserted directly into the byte size, and the object type is estimated based on the basic type. All you need is an approximate value.

For example, in each transaction, an order object is about 1KB, a coupon object is 2KB, a user object is 4KB, and a transaction record object is 4KB. In addition, there may be lists, arrays and so on. The number of objects generated in a single transaction is about 25KB.

A system with a daily transaction volume of 1 million, the transaction volume is concentrated in 6 hours, with an average maximum of 40 orders per second. This means that objects are generated at 1M per second. These generated objects are treated as garbage after a transaction, which means 1 MB garbage per second.

Assuming that we only have a 2-core 4G server, the memory allocated to the heap is generally about 1.5G. Through calculation, the size of each region in the heap can be calculated, as shown in the figure below:

According to the calculation, every 400 seconds, the 400M Eden area is full, and a Young GC will be performed. 98% of garbage will be collected, which means about 8M garbage will enter survivor transfers. Some objects fall into the old age after a few young GC’s, in which case the frequency of Full GC is very low. While 400 seconds is still slightly faster, youngGC has basically no effect on the system.

(iv) The estimation process under special business scenarios

Now the company plans to carry out a subsidy activity for one hour, during which the number of orders may be 20 times as much as before, which means 800 orders will be generated every second, and 20M garbage will be generated every second. What will happen?

The Eden area will be occupied in 20 seconds, and a youngGC will be executed every 20 seconds. At this time, due to too many orders, some interface responses may reach several seconds or even tens of seconds, and these objects will gradually enter the old age after several youngGC times. Generally, if FullGC occurs more than 2 times within an hour of being online, an alarm will be generated.

In this case, it means that we need to rethink our approach to machine resources and JVM memory.

The first consideration is to increase the MEMORY of JVM virtual machine. Due to hardware limitations, the improvement of THE MEMORY of JVM virtual machine should first improve the performance of the machine. We upgraded from dual-core 4G to 4-core 8G. 4.5g of memory allocated to the heap. In this case, the Eden area will have 1200M memory. Under the same conditions, youngGC will be executed once every 1 minute. Raising 20 seconds to 1 minute ensures that interface objects that are slow to respond can also be killed in youngGC instead of falling into the old age.

At the same time, we can upgrade one machine to three machines. After load balancing, the order pressure of each machine is 1/3 of the original, the youngGC time is increased to three times of the original, and the interface response time is accelerated. Basically, 3 4-core 8G machines can meet this activity.

(5) Summary

That doesn’t mean it’s all right. More machines need to be ready when it goes live, in case something goes wrong. Practice will give you the best answers.