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

This article mainly shows you the "Netty send queue backlog caused by memory leak how to do", the content is easy to understand, clear, hope to help you solve the doubt, the following let the editor lead you to study and learn "Netty send queue backlog caused by memory leak how to do" this article.

Text

There are many reasons for Netty memory leaks, such as the forgotten release of objects created using memory pools, or the backlog of send queues due to excessive pressure on peer system services.

Although NIO non-blocking communication is adopted in Netty, it is often not the bottleneck of system performance, but if the processing speed of the server is limited, the client sends a large amount of data, and does not do a good job of flow control, it will also lead to memory overflow.

Perform a performance stress test on a business, and multiple clients developed based on Netty are concurrently linked to a server. After the client runs for a period of time, the occupancy rate of memory and CPU remains high, and the response becomes slower and slower, and finally automatically downtime.

In order to facilitate the analysis, the code is simplified here. Here, a dead loop is used to send a message to the server to simulate the stress test environment. The client code is as follows:

Analysis of data Source Code sent by Netty

After the business calls the ChannelHandlerContext.write method and is processed by the ChannelPipeline responsibility chain, the message is delivered to the sending buffer to be sent, and the message is not really sent until flush is called.

The writeAndFlush method is called internally by the write method, and the code is as follows

Following the write () method, the processing logic is as follows: first determine whether the current thread is NioEventLoop, if not, encapsulate the sent data into a WriteTask, and the task queue put into NioEventLoop is executed by the NioEventLoop thread.

After making the same judgment in execute, here is the else branch, and after calling addTask (), add the task to the task queue

The NioEventLoop thread of Netty maintains a Queue taskQueue internally, which not only handles network Imax O read and write events, but also is responsible for network read and write related Task.

After a series of processing, after getting the data, the consumer will finally call the addMessage method of ChannelOutboundBuffer to add the message to the sending queue. Students who have studied data structure can clearly see that the sending queue is organized based on the linked list.

Note that the incrementPendingOutboundByte method called at the end of the method will be analyzed later. The phenomenon described at the beginning of the article is related to this method.

How to prevent the backlog of sending queues

In order to prevent the backlog of messages on the client caused by the slow processing of the server in the high concurrency scenario, in addition to the flow control on the server, the client also needs to do flow control and protect itself by setting the high and low water level of the queue to be sent.

There are two methods. The first is to set the option property in the startup class.

The second kind is

When the send queue reaches a high water level, the corresponding Channel becomes unwritable. Since the high water level does not affect the business thread calling the write method to write the message to the queue to be sent, the state of the Channel must be judged when the message is sent.

In order to control the sending speed of the sending queue, Netty provides a mechanism of high and low water level. when the backlog of messages reaches a high water level, modify Channel to unwritable state, in the ChannelOutboundBuffer class

After modifying the Channel status, call ChannelPipeline to send a notification message

When the backlog message is sent, the low water level is judged. If the number of bytes to be sent reaches or is lower than the low water level, the Channel status is changed to writable, and a notification event is sent. The code is as follows

After the above analysis, looking back at the problems described at the beginning of the article, we modify the code to the following format and then stress test, allowing the system to be stable after a period of time.

Memory consumption is as follows, which shows that the operation is very stable.

These are all the contents of the article "what to do about memory leaks caused by the backlog of Netty sending queues?" Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

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.