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 AFA3917877 for ; Wed, 1 Oct 2014 18:08:30 +0000 (UTC) Received: (qmail 16844 invoked by uid 500); 1 Oct 2014 18:08:30 -0000 Delivered-To: apmail-accumulo-user-archive@accumulo.apache.org Received: (qmail 16793 invoked by uid 500); 1 Oct 2014 18:08:30 -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 16780 invoked by uid 99); 1 Oct 2014 18:08:30 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Oct 2014 18:08:30 +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 (nike.apache.org: domain of eric.newton@gmail.com designates 209.85.220.173 as permitted sender) Received: from [209.85.220.173] (HELO mail-vc0-f173.google.com) (209.85.220.173) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Oct 2014 18:08:03 +0000 Received: by mail-vc0-f173.google.com with SMTP id ij19so646474vcb.32 for ; Wed, 01 Oct 2014 11:08:02 -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=eRd/11Hy7znqP/Ha4kl7KMwGT2+XH3j/JWeoZhXMQvA=; b=G+cvzJSgvkQ73MWOJquDKdbR4NqPzD1Hp/Bm9LYrFvfm6jNCT9ntCXtcH1Am2Behky 2sJGq+KrmbyFFrGpA5R9RCBR2BiRK4Yp0iJh6DvwYykU8E6q9fkuEtn3ys3yaSIaGhWO fCemPFxUEq1UmxKMIOWRCbcov6BFChjZ9PB5+MHUsXGYF7PMoRPB16ggfAgS6c1q0hF4 ISR/yXJ1oh6pfsxarpSQ23r2XcTCera12OEdPLxuuG0wJFkigCcwZV8oxLW7p60GayfK IuqDkS+/DkBqB4cGy6h1ixZXQDSo/DSGU16cSz3rYDKVMZP6v0FLWntE0sDFTHGqXWFQ 8TrQ== MIME-Version: 1.0 X-Received: by 10.221.34.73 with SMTP id sr9mr2469109vcb.45.1412186882258; Wed, 01 Oct 2014 11:08:02 -0700 (PDT) Received: by 10.31.134.75 with HTTP; Wed, 1 Oct 2014 11:08:02 -0700 (PDT) In-Reply-To: References: <542AD794.8070403@gmail.com> Date: Wed, 1 Oct 2014 14:08:02 -0400 Message-ID: Subject: Re: Out of memory when putting many rows in an Acc table From: Eric Newton To: "user@accumulo.apache.org" Content-Type: multipart/alternative; boundary=001a113654807959810504606125 X-Virus-Checked: Checked by ClamAV on apache.org --001a113654807959810504606125 Content-Type: text/plain; charset=UTF-8 > > I realized this could be due to an inability by the JVM to create > additional native threads You may need to increase the nproc limit on your systems. -Eric On Wed, Oct 1, 2014 at 11:12 AM, Geoffry Roberts wrote: > Thanks for the response. > > The only reason I was creating q new BatchWriter periodically was to > determine if BatchWriter was holding on to memory even after a flush. I > had memory on my BatchWriterConfig set to 1M already. I am reading my RDB > tables in pages of 10K rows. > > Bumping up the JVM size didn't help, > > I tried setting -XX:+HeapDumpOnOutOfMemoryError and when it did not > produce any output (hprof file). I realized this could be due to an > inability by the JVM to create additional native threads. > > What I now think is the problem is not with Acc directly but hiding out on > the JDBC side. > > Perhaps this is not an Acc issue at all but merely masquerading as one. > We'll see. > > > On Tue, Sep 30, 2014 at 12:17 PM, Josh Elser wrote: > >> You shouldn't have to create a new BatchWriter -- have you tried reducing >> the amount of memory the BatchWriter will use? It keeps a cache internally >> to try to do an amortization of Mutations to send to a given tabletserver. >> >> To limit this memory, use the BatchWriterConfig#setMaxMemory(long) >> method. By default, the maxMemory value is set to 50MB. Reducing this may >> be enough to hold less data in your client and give you some more head room. >> >> Alternatively, you could give your client JVM some more heap :) >> >> >> Geoffry Roberts wrote: >> >>> I am try to pump some data into Accumulo but I keep encountering >>> >>> Exception in thread "Thrift Connection Pool Checker" >>> java.lang.OutOfMemoryError: Java heap space >>> >>> at java.util.HashMap.newValueIterator(HashMap.java:971) >>> >>> at java.util.HashMap$Values.iterator(HashMap.java:1038) >>> >>> at >>> org.apache.accumulo.core.client.impl.ThriftTransportPool$Closer. >>> closeConnections(ThriftTransportPool.java:103) >>> >>> at >>> org.apache.accumulo.core.client.impl.ThriftTransportPool$Closer. >>> run(ThriftTransportPool.java:147) >>> >>> at java.lang.Thread.run(Thread.java:745) >>> >>> >>> I tried, as a work around, creating a new BatchWriter and closing the >>> old one every ten thousand rows, but to no avail. Data gets written up >>> to the 200kth row, then the error. >>> >>> I have a table of 8M rows in a RDB that I am pumping into Acc via a >>> groovy script. The rows are narrow, a short text field and four floats. >>> >>> I googled of course but nothing was helpful. What can be done? >>> >>> Thanks so much. >>> >>> -- >>> There are ways and there are ways, >>> >>> Geoffry Roberts >>> >> > > > -- > There are ways and there are ways, > > Geoffry Roberts > --001a113654807959810504606125 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I=C2=A0realized this could be d= ue to an inability by the JVM to create additional native threads

You may need to increase= the nproc limit on your systems.

-Eric
=C2=A0

On Wed, O= ct 1, 2014 at 11:12 AM, Geoffry Roberts <threadedblue@gmail.com&g= t; wrote:
Thanks = for the response.

The only reason I was creating q new B= atchWriter periodically was to determine if BatchWriter was holding on to m= emory even after a flush. =C2=A0 I had memory on my BatchWriterConfig set t= o 1M already.=C2=A0 I am reading my RDB tables in pages of 10K rows. =C2=A0=

Bumping up the JVM size didn't help, =C2=A0

I tried setting=C2=A0-XX:+HeapDumpOnOutOfMemoryError and when it did not p= roduce any output (hprof file). I=C2=A0realized this could be due to an ina= bility by the JVM to create additional native threads.=C2=A0<= /font>

What I now think is the problem is n= ot with Acc directly but hiding out on the JDBC side. =C2=A0

=
Perhaps this is not an Acc issue at all but merely masquerading = as one.=C2=A0 We'll see.


On Tue, Sep 30, 2014 at 12:17 PM, Jos= h Elser <josh.elser@gmail.com> wrote:
You shouldn't have to create a new BatchWriter -- have you tried reduc= ing the amount of memory the BatchWriter will use? It keeps a cache interna= lly to try to do an amortization of Mutations to send to a given tabletserv= er.

To limit this memory, use the BatchWriterConfig#setMaxMemory(long) m= ethod. By default, the maxMemory value is set to 50MB. Reducing this may be= enough to hold less data in your client and give you some more head room.<= br>
Alternatively, you could give your client JVM some more heap :)

Geoffry Roberts wrote:
I am try to pump some data into Accumulo but I keep encountering

Exception in thread "Thrift Connection Pool Checker"
java.lang.OutOfMemoryError: Java heap space

at java.util.HashMap.newValueIterator(HashMap.java:971)

at java.util.HashMap$Values.iterator(HashMap.java:1038)

at
org.apache.accumulo.core.client.impl.ThriftTransportPool$Clos= er.closeConnections(ThriftTransportPool.java:103)

at
org.apache.accumulo.core.client.impl.ThriftTransportPool$Clos= er.run(ThriftTransportPool.java:147)

at java.lang.Thread.run(Thread.java:745)


I tried, as a work around, creating a new BatchWriter and closing the
old one every ten thousand rows, but to no avail.=C2=A0 Data gets written u= p
to the 200kth row, then the error.

I have a table of 8M rows in a RDB that I am pumping into Acc via a
groovy script.=C2=A0 The rows are narrow, a short text field and four float= s.

I googled of course but nothing was helpful.=C2=A0 What can be done?

Thanks so much.

--
There are ways and there are ways,

Geoffry Roberts



--
=
There are ways and there are ways,=C2=A0
Geoffry Roberts

--001a113654807959810504606125--