Return-Path: X-Original-To: apmail-accumulo-user-archive@www.apache.org Delivered-To: apmail-accumulo-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id A6ABA109AE for ; Mon, 28 Oct 2013 22:20:44 +0000 (UTC) Received: (qmail 17139 invoked by uid 500); 28 Oct 2013 22:20:44 -0000 Delivered-To: apmail-accumulo-user-archive@accumulo.apache.org Received: (qmail 17109 invoked by uid 500); 28 Oct 2013 22:20:44 -0000 Mailing-List: contact user-help@accumulo.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@accumulo.apache.org Delivered-To: mailing list user@accumulo.apache.org Received: (qmail 17101 invoked by uid 99); 28 Oct 2013 22:20:44 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 28 Oct 2013 22:20:44 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of texpilot@gmail.com designates 74.125.83.53 as permitted sender) Received: from [74.125.83.53] (HELO mail-ee0-f53.google.com) (74.125.83.53) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 28 Oct 2013 22:20:39 +0000 Received: by mail-ee0-f53.google.com with SMTP id e51so1757177eek.12 for ; Mon, 28 Oct 2013 15:20:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=lP9U38fs4Lwc1lu3xeZoDxn2M8OCOgfAYAkEeNy7jV4=; b=FBg7TTY1jnQk30aPrNAPULX9BHbJM899n0WdFKcpN/MHYb7CZlQSQifY2YTkBn60g1 /kVqwBW83rye4vQLjgi/NV/mjH1k1IfKLfOHEDQJTIaLvXRC4hz2xYragfQWShqT7AgF 1Syw29T+PkbQPq1LyELAYeZEJerDLuZtkW1Tx7bEN9himYErXFujOgJoHtUu+qHyGSEM sUe4JGqj+SxwGVUfLF40s2TB+ovzzDzF4byi+fAA2yATFcupq2R/UVKWJCcC39VncsDn T49AILnVVFYTs84Du2RqLo7GEjnP3BzQHobVXLl0Q1tmUVPIxWFeZqRBf8IQRepESC3f L2FA== MIME-Version: 1.0 X-Received: by 10.14.110.130 with SMTP id u2mr26149eeg.144.1382998818547; Mon, 28 Oct 2013 15:20:18 -0700 (PDT) Received: by 10.223.87.74 with HTTP; Mon, 28 Oct 2013 15:20:18 -0700 (PDT) In-Reply-To: References: Date: Mon, 28 Oct 2013 17:20:18 -0500 Message-ID: Subject: Re: How to reduce number of entries in memory From: "Terry P." To: "user@accumulo.apache.org" Content-Type: multipart/alternative; boundary=089e0162837e4ded3804e9d4810d X-Virus-Checked: Checked by ClamAV on apache.org --089e0162837e4ded3804e9d4810d Content-Type: text/plain; charset=UTF-8 Thanks for the replies. I was approaching it from a data integrity perspective, as in wanting it flushed to disk in case of a TabletServer failure. Last weekend we saw two TabletServers exit the cluster due to a network glitch, and wouldn't you know that the 04 node was secondary logger for the 03 node. In our case, these entries are hanging around in memory *for hours*, as the ingest rate is not that high. Perhaps an hourly flush of the table via the shell to get it out to disk would be the way to go? On Mon, Oct 28, 2013 at 4:30 PM, Mike Drob wrote: > What are you trying to accomplish by reducing the number of entries in > memory? A tablet server will not minor compact (flush) until the native map > fills up, but keeping things in memory isn't really a performance concern. > > You can force a one-time minor compaction via the shell using the 'flush' > command. > > > On Mon, Oct 28, 2013 at 5:19 PM, Terry P. wrote: > >> Greetings all, >> For a growing table that currently from zero to 70 million entries this >> weekend, I'm seeing 4.4 million entries still in memory, though the client >> programs are supposed to be flushing their entries. >> >> Is there a server-side setting to help reduce the number of entries that >> are in memory (not yet flushed to disk)? Our system has fairly light >> performance requirements, so I'm okay if a tweak may result in reduced >> ingest performance. >> >> Thanks in advance, >> Terry >> > > --089e0162837e4ded3804e9d4810d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the replies. I was approaching it fro= m a data integrity perspective, as in wanting it flushed to disk in case of= a TabletServer failure.=C2=A0 Last weekend we saw two TabletServers exit t= he cluster due to a network glitch, and wouldn't you know that the 04 n= ode was secondary logger for the 03 node.

In our case, these entries are hanging around in memory for ho= urs, as the ingest rate is not that high.

Perhaps an hourl= y flush of the table via the shell to get it out to disk would be the way t= o go?


On Mon,= Oct 28, 2013 at 4:30 PM, Mike Drob <mdrob@mdrob.com> wrote:
What are you trying to accomplish by reducing the num= ber of entries in memory? A tablet server will not minor compact (flush) un= til the native map fills up, but keeping things in memory isn't really = a performance concern.

You can force a one-time minor compaction via the shell using the= 'flush' command.
=


On Mon, Oct 2= 8, 2013 at 5:19 PM, Terry P. <texpilot@gmail.com> wrote:
Greetings all,
For a growing table that currently from zero to 70 million entries t= his weekend, I'm seeing 4.4 million entries still in memory, though the= client programs are supposed to be flushing their entries.

Is there a server-side setting to help reduce the number of = entries that are in memory (not yet flushed to disk)?=C2=A0 Our system has = fairly light performance requirements, so I'm okay if a tweak may resul= t in reduced ingest performance.

Thanks in advance,
Terry


--089e0162837e4ded3804e9d4810d--