You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-issues@hadoop.apache.org by "fanshilun (Jira)" <ji...@apache.org> on 2022/11/21 05:51:00 UTC

[jira] [Comment Edited] (HADOOP-18534) Propose a mechanism to free the direct memory occupied by RPC Connections

    [ https://issues.apache.org/jira/browse/HADOOP-18534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17636453#comment-17636453 ] 

fanshilun edited comment on HADOOP-18534 at 11/21/22 5:50 AM:
--------------------------------------------------------------

Usually an rpc request is returned in milliseconds. At this time, I think the impact of GC can be ignored. A large HDFS system, the Audit Log will record 100-200 million requests, and I have not seen any abnormalities in rpc client gc.

RPC service is the core service of the whole system. We need to clarify the benefits before modifying it, otherwise it will bring great risks.


was (Author: slfan1989):
Usually an rpc request is returned in milliseconds. At this time, I think the impact of GC can be ignored.

> Propose a mechanism to free the direct memory occupied by RPC Connections
> -------------------------------------------------------------------------
>
>                 Key: HADOOP-18534
>                 URL: https://issues.apache.org/jira/browse/HADOOP-18534
>             Project: Hadoop Common
>          Issue Type: Improvement
>          Components: rpc-server
>            Reporter: xinqiu.hu
>            Priority: Minor
>         Attachments: 未命名文件 (1).png
>
>
>   In the RPC Client, a thread called RpcRequestSender is responsible for writing the connection request to the socket. Every time a request is sent, a direct memory is applied for in sun.nio.ch.IOUtil#write() and cached.
>   If Connection and RpcRequestSender are promoted to the old generation, they will not be recycled when full gc is not performed, resulting in the DirectByteBuffer cached in sun.nio.ch.Util not being recycled. When the memory occupied by DirectByteBuffer is too large, the jvm process may not have the opportunity to do full gc and is killed.
>   Unfortunately, there is no easy way to free these DirectByteBuffers. Perhaps, we can manually free these DirectByteBuffers by the following methods when the Connection is closed.
> {code:java}
> private void freeDirectBuffer() {
>   try {
>     ByteBuffer buffer = Util.getTemporaryDirectBuffer(1);
>     int i = 0;
>     while (buffer.capacity() != 1 && i < 1024) {
>       ((DirectBuffer) buffer).cleaner().clean();
>       buffer = Util.getTemporaryDirectBuffer(1);
>       i++;
>     }
>     ((DirectBuffer) buffer).cleaner().clean();
>   } catch (Throwable t) {
>     LOG.error("free direct memory error, connectionId: " + remoteId, t);
>   }
> }{code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-issues-help@hadoop.apache.org