Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jira@apache.org
Date: Thu, 2 Jan 2014 18:01:58 +0000 (UTC)
From: "Keith Turner (JIRA)" <jira@apache.org>
To: notifications@accumulo.apache.org
Message-ID: <JIRA.12654843.1372202902058.31850.1388685718826@arcas>
In-Reply-To: <JIRA.12654843.1372202902058@arcas>
References: <JIRA.12654843.1372202902058@arcas>
Subject: [jira] [Commented] (ACCUMULO-1534) Tablet Server using large number
 of decompressors during a scan
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Keith Turner commented on ACCUMULO-1534:
----------------------------------------

Its not fixed, the config change just dropped the memory usage by 8x.   If someone allocates  a lot of decompressors then they can still run into this problem.

> Tablet Server using large number of decompressors during a scan
> ---------------------------------------------------------------
>
>                 Key: ACCUMULO-1534
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-1534
>             Project: Accumulo
>          Issue Type: Bug
>    Affects Versions: 1.4.3
>            Reporter: Mike Drob
>            Assignee: Keith Turner
>            Priority: Critical
>             Fix For: 1.5.1, 1.6.0
>
>
> I believe this issue is similar to ACCUMULO-665. We've run into a situation where a complex iterator tree creates a large number of decompressors from the underlying CodecPool for serving scans. Each decompressor holds on to a large buffer and the total volume ends up killing the tserver.
> We have verified that turning off compression makes this problem go away.


--
This message was sent by Atlassian JIRA
(v6.1.5#6160)