hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Misty Stanley-Jones (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HBASE-11492) Hadoop configuration overrides some ipc parameters including tcpNoDelay
Date Tue, 15 Jul 2014 00:56:07 GMT

     [ https://issues.apache.org/jira/browse/HBASE-11492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Misty Stanley-Jones updated HBASE-11492:
----------------------------------------

    Release Note: 
If the Hadoop configuration is read after the HBase configuration, Hadoop's settings can override
HBase's settings if the names of the settings are the same. To avoid the risk of override,
HBase has renamed the following settings (by prepending 'hbase.') so that you can set them
independent of your setting for Hadoop. If you do not use the HBase-specific variants, the
Hadoop settings will be used.

Old Name   -->   New Name
======================================================
ipc.server.listen.queue.size   -->   hbase.ipc.server.listen.queue.size
ipc.server.max.callqueue.size   -->   hbase.ipc.server.max.callqueue.size
ipc.server.read.threadpool.size   -->   hbase.ipc.server.read.threadpool.size
ipc.server.tcpkeepalive   -->   hbase.ipc.server.tcpkeepalive
ipc.server.tcpnodelay   -->   hbase.ipc.server.tcpnodelay
ipc.client.call.purge.timeout   -->   hbase.ipc.client.call.purge.timeout
ipc.client.connection.maxidletime   -->   hbase.ipc.client.connection.maxidletime
ipc.client.idlethreshold   -->   hbase.ipc.client.idlethreshold
ipc.client.kill.max   -->   hbase.ipc.client.kill.max


  was:
If the Hadoop configuration is read after the HBase configuration, Hadoop's settings can override
HBase's settings if the names of the settings are the same. To avoid the risk of override,
HBase has renamed the following settings (by prepending 'hbase.') so that you can set them
independent of your setting for Hadoop. If you do not use the HBase-specific variants, the
Hadoop settings will be used.

Old Name   -->   New Name
====================================================================
ipc.server.listen.queue.size   -->   hbase.ipc.server.listen.queue.size
ipc.server.max.callqueue.size   -->   hbase.ipc.server.max.callqueue.size
ipc.server.read.threadpool.size   -->   hbase.ipc.server.read.threadpool.size
ipc.server.tcpkeepalive   -->   hbase.ipc.server.tcpkeepalive
ipc.server.tcpnodelay   -->   hbase.ipc.server.tcpnodelay
ipc.client.call.purge.timeout   -->   hbase.ipc.client.call.purge.timeout
ipc.client.connection.maxidletime   -->   hbase.ipc.client.connection.maxidletime
ipc.client.idlethreshold   -->   hbase.ipc.client.idlethreshold
ipc.client.kill.max   -->   hbase.ipc.client.kill.max



> Hadoop configuration overrides some ipc parameters including tcpNoDelay
> -----------------------------------------------------------------------
>
>                 Key: HBASE-11492
>                 URL: https://issues.apache.org/jira/browse/HBASE-11492
>             Project: HBase
>          Issue Type: Bug
>          Components: regionserver
>    Affects Versions: 0.98.0, 0.99.0
>            Reporter: Nicolas Liochon
>            Assignee: Nicolas Liochon
>            Priority: Critical
>             Fix For: 0.99.0, 0.98.4, 2.0.0
>
>         Attachments: 11492.v1.patch, 11492.v1.withp1.patch, 11492.v2-0.98.patch, 11492.v2.patch,
11492.v2.patch
>
>
> There is an option to set tcpNoDelay, defaulted to true, but the socket channel is actually
not changed. As a consequence, the server works with nagle enabled. This leads to very degraded
behavior when a single connection is shared between threads. We enter into conflicts with
nagle and tcp delayed ack. 
> Here is an example of performance with the PE tool plus HBASE-11491:
> {noformat}
> oneCon     #client       sleep          exeTime (seconds)                           
 avg latency, sleep excluded (microseconds)
> true           1               0                31                                  
                  310
> false          1               0                31                                  
                  310
> true           2               0                50                                  
                   500
> false          2               0               31                                   
                  310
> true           2                5               488 (including 200s sleeping)       
       2880 
> false          2               5               246  (including 200s sleeping)       
       460
> {noformat}
> The latency is multiple by 5 (2880 vs 460) when the connection is shared. This is the
delayed ack kicking in. This can be fixed by really using tcp no delay.
> Any application sharing the tcp connection between threads has the issue.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message