Shulou(Shulou.com)06/02 Report--

This article introduces the knowledge of "how to build high-performance Java applications". Many people will encounter this dilemma in the operation of actual cases, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

For performance tuning, there are usually three steps: 1, performance monitoring; 2, performance analysis; 3, performance tuning

Our focus on the performance of the operating system is mainly on the following points: CPU utilization, CPU scheduling execution queue, memory utilization, network ID O, disk ID O.

1.CPU utilization

For an application, in order to achieve the performance and scalability of the application, we should not only make full use of the parts available in the CPU cycle, but also make the use of this part of the CPU more valuable rather than wasteful. It is challenging for multithreaded applications to run on multi-processor and multi-core systems to make full use of CPU cycles. In addition, when the CPU reaches saturation, it does not mean that the performance and scalability of CPU have reached the state of * *. In order to distinguish how applications utilize CPU resources, we must detect them at the operating system level. On many operating systems, CPU utilization statistics usually include users and system or kernel usage of the operating system. The user's use of CPU refers to the time it takes for the application to execute the application code. By contrast, the use of CPU by the kernel and system refers to the time it takes for the application to execute code locks in the operating system kernel. High kernel or system CPU usage can indicate that shared resources are urgent, or that there are a large number of Imax O devices interacting. Ideally, in order to improve the performance and scalability of the application, the kernel or system CPU time is 0%, because the time spent executing the kernel or system code can be used to execute the application code. So one of the right directions for CPU to use optimization is to minimize the time CPU spends executing kernel or system code.

For compute-intensive applications, performance monitoring is deeper than monitoring user CPU usage and kernel or system CPU usage. In compute-intensive applications, we need to monitor the number of execution lines in the CPU clock cycle (Instructions per clock;IPC) or the CPU cycle used by each CPU execution (cycles per instruction;CPI). For compute-intensive applications, it is a good choice to monitor CPU from these two dimensions, because the packaged CPU performance reporting tools of modern operating systems usually print only the utilization of CPU, not the time spent by CPU to execute instructions during the CPU cycle. This means that when CPU is waiting for data in memory, the operating system CPU performance reporting tool will also think that CPU is in use. We call this scenario "Stall", and "Stall" scenarios often occur. For example, whenever CPU is executing instructions, as long as the data required by the instructions is not ready, that is, it is not in the register or CPU cache, "Stall" scenarios will occur.

When the "Stall" scenario occurs, the CPU wastes clock cycles because the CPU has to wait for the data required by the instruction to reach the register or buffer. And in this scenario, it is normal for hundreds of CPU clock cycles to be wasted, so in compute-intensive applications, the strategy to improve performance is to reduce the occurrence of "Stall" scenarios or to enhance CPU cache usage so that fewer CPU cycles are wasted waiting for data. This kind of performance monitoring knowledge has gone beyond the content of this book and needs the help of performance experts. However, such data will be included in a performance profiling tool like Oracle Solaris Studio Performance Analyzer, which will be discussed later.

2.CPU scheduling queue

In addition to monitoring CPU usage, we can also check whether the system is fully loaded by monitoring the CPU execution queue. Execution queues are used to store lightweight processes, which are usually ready to execute but are waiting for CPU scheduling while waiting in the scheduling queue. Scheduling queues will be generated when more lightweight processes can be processed in time by the current processor. The deep CPU scheduling queue indicates that the system is at full capacity. The execution queue depth of the system is equal to the number of waits that the virtual processor cannot perform, and the number of virtual processors is equal to the number of hardware threads of the system. We can use java's api to get the number of virtual pseudo-processors, Runtime.avaliableProcessors (). When the execution queue depth is more than four times or more than the number of virtual processors, the operating system will be slow to respond.

A general guide for the detection of CPU scheduling queues is to pay attention when we find that the queue depth is more than twice the number of virtual processes, but there is no need to take immediate action. Pay attention when it is more than three times or four times or higher, and it is urgent to solve the problem.

There are usually two optional ways to observe the depth of the queue, * one is to increase the CPU to share the load or reduce the load on the existing CPU. This approach essentially reduces the number of load threads per execution unit, thereby reducing the depth of the execution queue.

Another way is to increase the utilization of CPU by analyzing the applications running by the system, in other words, to find a way to reduce the CPU cycle spent on garbage collection, or to find a better algorithm to execute CPU instructions with fewer CPU cycles. Performance experts usually focus on the latter approach: reducing the length of the code execution path and better choice of CPU instructions. JAVA programmers can improve the efficiency of code execution by better executing algorithms and data structures.

3. Memory utilization

In addition to CPU usage, the system's memory properties also need to be monitored, such as paging, swapping, locking, context swapping caused by multithreading, and so on.

Swapping usually occurs when the application needs more memory than the actual physical memory, and the operating system usually configures a corresponding area called the swap area. The swap area is usually located on the physical disk. When the application in the physical memory is exhausted, the operating system will temporarily swap part of the memory data to the disk space. This part of the memory area is usually an area of access frequency. Without affecting the more "busy" memory area. When the memory swapped to the disk area is accessed by the application, it is necessary to read the memory in pages from the disk swap area, and swapping will affect the performance of the application.

The performance of the virtual machine garbage collector is very poor when swapping, because most of the areas accessed by the garbage collector are unreachable, that is, the garbage collector will cause exchange activity. The scenario is dramatic. If the heap area of the garbage collection has been swapped to disk space, it will be swapped in pages so that it can be scanned by the garbage collector. During the exchange, the collection time of the garbage collector will be dramatically increased. At this time, if the garbage collector is "Stop The World" (causing the application response to stop), the time will be extended.

4. Network Ipaw O

The performance and scalability of distributed JAVA applications are limited by network bandwidth and network performance. For example, if we send more packets to the network interface than he can handle, the packets will accumulate in the buffer of the operating system, which will cause application delay, and other situations will also lead to network application delay.

Tools for distinguishing and monitoring are often difficult to find in the packaging tools of the operating system. Although linux provides netstat commands, linux and solaris both provide implementations of network usage, including statistics on sending packets per second, receiving packets, packet errors, conflicts, and so on. In Ethernet, it is normal for a small number of packets to collide. If there are many wrong packets, there may be something wrong with the network card. At the same time, although netstat can count the data sent and received by the network interface, it is difficult to determine whether the network card is fully utilized. For example, if netstat-I shows that 2500 packets are sent from the Nic every second, but we still can't tell whether the current network utilization is 100% or 1%, we can only know that there is traffic. This is only a conclusion that can be obtained without knowing the size of the network packet. To put it simply, we cannot tell whether the current network is affecting performance by the netstat provided by linux and solaris. We need some other tools to monitor the network while our JAVA application is running.

5. Disk IPUBO

If the application operates on the disk, we need to monitor the disk to monitor for possible disk performance problems. Some applications are Imax O-intensive, such as databases. The use of disks usually exists in the application log system, which is usually used to record important information during the operation of the system.

This is the end of "how to build high-performance Java applications". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.