Abstract
In project development, we usually first need to set the JVM memory requirements of the project before the project goes live. So our general idea is as follows: online business system process carding – daily data visits of > – QPS of > peak -> calculates computer machine configuration (1, how many machines are needed 2, how much memory of each machine is 3, each machine JVM parameter setting)-> system expansion 10-20 times estimated (generally our system will be 10-20 times larger than the estimated);
The JVM memory parameters for each machine are the key: we need to calculate how much data the machine will enter into the Java heap each time the new generation of Minor /Young GC is triggered based on the concurrency, the size of each request, and the processing time of each request.
content
At present, according to the business background of the project to do a general business process reorganization, and then according to the configuration analysis of the machine to set the memory parameters of the JVM.
Online system business process abstraction
The first is core business process simplification, abstraction, and grooming. On the project at present is to be smart to call system, core process is the third party system/application system front-end import data warehousing, then create the corresponding task rules, outbound platform according to the rules of the corresponding task for the call, due to the complex rules call, call to call platform, you need to call the core application system two interfaces: 1. Outbound call recall wheel call interface: mainly for one person with many numbers, for the unconnected or connected number to do whether to call this number again, if not recall, whether to initiate the wheel call. 2. Number firewall interface: this interface is mainly the number verification when the platform calls, whether a number is on the white list, black list, and whether the call is restricted every day, as well as some number transformation (according to the service number to get the real number, called number decryption)
Then, after the platform finishes calling, the call results will be stored in the database, and the application system’s timing dispatching will query out 100 data interfaces each time and return them to the third-party system. The simplified business flow chart is as follows:
System QPS
The peak volume of system call results is about 200,000, and the average number connection rate is 50%. The average number of uncalled numbers is called three times, and one number may be more than one number. We calculate according to one person and one number, and the transmission of call results has different timing transmission tasks according to the number of our tripartitioned systems. At present, there are four tripartite systems docking. Therefore, we estimate the amount of data entering the intelligent outbound calling system every day as follows: total data = 200,000 (outbound calling platform – number firewall interface)+ 100,000 (access data)+ 150,000 (recall wheel calling interface)+ 200,000 (result return)+ 50,000 (others)= 700,000, and the calling time every day is about 8 hours; Since outgoing system calls are automatically triggered in the background, there is no 80% data volume flooding in 20% of the time. So QPS is :700000/8/60/60=25;
JVM parameter estimation.
How many requests per second 25 requests per second
Time spent on each request: 200,000 yuan (outbound platform – number firewall interface – 1 second on average)+ 100,000 yuan (access data -8 seconds)+ 150,000 yuan (recall wheel calling interface – 3 seconds on average)+ 200,000 yuan (result return -200 ms)+ 50,000 yuan (other)= 700,000 yuan
Number firewall interface: 1 second on average
Time to access data: We estimate about 8 seconds.
Heavy breath: We estimate about 3 seconds.
The results of return: An average of 200 ms
The total time for each request is approximately (20+10×8+15×3+20×0.2+5)/70=2.17 seconds.
How much memory is required per request? Each request has an average of more than 20 fields, about 500B
Memory footprint per second of requests? There are 25 requests per second and each request size is 500B, so the memory footprint of the requests made per second is: 25x500B = 12.2KB
Estimate the full system memory footprint required. We just for the system to call when access to evaluate data volume, outside the real system operation, will certainly create a large number of other objects, every second, are more likely to be more data in one minute when trigger greater data concurrency, combined with this we can roughly estimate the whole system every second about how much memory space, we once again based on the calculated results expand 10 ~ 20 times. That is, every second between 120KB and 250KB is created in the Java heap memory, and the next second it triggers a new generation of garbage, which then triggers a Minor GC to collect the garbage.
How should the system’s JVM heap memory be set?
In fact, the general on-line business system, the common machine configuration is 2 cores, 4G, or 4 cores, 8G; Calculate according to 2 cores 4G: 4G memory allocated to the JVM virtual machine memory is 2G; JVM virtual machine runs in addition to Java heap memory, Java virtual machine stack, program counter, method area; The size of the memory we allocate to Java is generally accounted for more than half, that is, more than 1G,Java heap has the new generation and the old age, according to the Java object is mostly “life “, our new generation and the old age is about 8:2, that is, the new generation is 800M; 250 kilobytes of new objects enter the system every second; So 800 x1024/250/60 = 55 min; That’s about 55 minutes to trigger a Minor GC, so that’s enough.
How should the JVM heap memory be set for a system that is concurrently scaling up by 10 times?
If the system concurrency is increased by a factor of 10, or 250 requests per second, then 1200Kb to 2500Kb will enter the Java heap every second, which is equal to 2M. – 800/2/60=7 minutes – a Minor collection will occur every 7 minutes. Frequent occurrences will affect system performance.
If we use 4 cores with 8GB, we allocate 4GB of memory to the JVM virtual machine, then the Java heap memory is 2GB, the next-generation footprint: 1.6GB, then 1.6×1024/2/60=13 minutes, then we also cause Minor GC is frequent, so we can make the JVM virtual machine 5G, and then the Java heap is 3G, so the new generation is :2.4G, so :2.4×1024/2/60=21 minutes, about 21 minutes to trigger a Minor GC is OK.
So parameter setting:
- Xms3G - Xmx3G - Xmn2.4 G
Failure to set JVM parameters properly
If the JVM parameters are not set reasonably, in the case of large concurrent amount, if the machine itself has less memory :2 cores, 4G, the allocated Java heap memory is relatively small, for example, the new generation and old generation in the Java heap memory are allocated 500M each, the business concurrent amount is 1000, the data volume object is dozens of M per second, and the thread, network, memory, etc A number of factors can cause each request to take longer, and in the worst case scenario, dozens of megabytes of objects per second will enter the new generation, and when the new generation fills up, a frequent minor collection will be triggered, with a dozen or so minor collections due to processing delays Gc, after the request data is not processed, the inside of the Java heap memory object also survive, so will enter old age, old age will be more and more, and then the old s rubbish will be more and more, leading to frequent garbage collection, old s due to the recycling of the old s “mark – up” method, the effect is very poor, can finally lead to system is very poor.
How to set the permanent generation size?
General permanent generation just started on-line a system, not too much reference specification, generally set up about a few hundred MB, in general is enough, because it is mainly to store some class of information.
How to set a reasonable stack memory size?
The size of the stack memory is generally not expected and set. The default size is 512KB to 1MB. This is the stack memory space of each thread, which holds various layout variables during the execution of the thread method.