Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Fri, 7 Sep 2012 10:43:08 +1100 (NCT)
From: "Kannan Muthukkaruppan (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <663714423.47382.1346974988237.JavaMail.jiratomcat@arcas>
In-Reply-To: <1037526073.45626.1346954470241.JavaMail.jiratomcat@arcas>
Subject: [jira] [Updated] (HBASE-6727) [89-fb] allow HBaseServers's
 callqueue to be better configurable to avoid OOMs
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Kannan Muthukkaruppan updated HBASE-6727:
-----------------------------------------

    Description: 
The callQueue size (where requests get queued up if all handlers are busy) is a LinkedBlockingQueue of size 100 * number_of_handlers. So, with say 300 handler threads, the call queue can have upto 30k entries queued up. If the requests are large enough, this can result in OOM or severe GC pauses.

Ideally, we should allow this param to be separately configurable independent of the numberof handlers; perhaps an even better approach would be to specify a memory size based limit, instead of a number of entries based limit.

[I have not looked at the trunk version for this issue. So it may or may not be relevant there.]

  was:
The callQueue size (where requests get queued up if all handlers are busy) is a LinkedBlockingQueue of size 100*# of handlers. So, with say 300 handler threads, the call queue can have upto 30k entries queued up. If the requests are large enough-- then this can result in OOM or severe GC pauses.

Ideally, we should allow this param to be separately configurable independent of the # of handlers; and better still be able to specify a memory size based limit, instead of a # of entries based limit.

[I have not looked at the trunk version for this issue. So it may or may not be relevant there.]

    
> [89-fb] allow HBaseServers's callqueue to be better configurable to avoid OOMs
> ------------------------------------------------------------------------------
>
>                 Key: HBASE-6727
>                 URL: https://issues.apache.org/jira/browse/HBASE-6727
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Kannan Muthukkaruppan
>            Assignee: Michal Gregorczyk
>
> The callQueue size (where requests get queued up if all handlers are busy) is a LinkedBlockingQueue of size 100 * number_of_handlers. So, with say 300 handler threads, the call queue can have upto 30k entries queued up. If the requests are large enough, this can result in OOM or severe GC pauses.
> Ideally, we should allow this param to be separately configurable independent of the numberof handlers; perhaps an even better approach would be to specify a memory size based limit, instead of a number of entries based limit.
> [I have not looked at the trunk version for this issue. So it may or may not be relevant there.]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira