Return-Path: X-Original-To: apmail-flume-user-archive@www.apache.org Delivered-To: apmail-flume-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 DEAA411510 for ; Mon, 4 Aug 2014 21:55:49 +0000 (UTC) Received: (qmail 37020 invoked by uid 500); 4 Aug 2014 21:55:49 -0000 Delivered-To: apmail-flume-user-archive@flume.apache.org Received: (qmail 36964 invoked by uid 500); 4 Aug 2014 21:55:49 -0000 Mailing-List: contact user-help@flume.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@flume.apache.org Delivered-To: mailing list user@flume.apache.org Received: (qmail 36954 invoked by uid 99); 4 Aug 2014 21:55:49 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Aug 2014 21:55:49 +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 roshan@hortonworks.com designates 209.85.219.45 as permitted sender) Received: from [209.85.219.45] (HELO mail-oa0-f45.google.com) (209.85.219.45) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Aug 2014 21:55:45 +0000 Received: by mail-oa0-f45.google.com with SMTP id i7so48750oag.18 for ; Mon, 04 Aug 2014 14:55:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=BJkYE693XSwEAZDFbIbXdXT5nCYbZcWdZ1s+g+8Ll6Y=; b=k3D3/rjilQmn89KCLLaXhPr86vIq5iVv+WRdG5NfD/rwkjKDtConk68PWpn+DuG1oa Efdc1vtbaJYOO5UReppHUlukW26THBCYVqgk/6W9LjCKoBFVLgk7p2/JQEuIErw7eHia U3Y8AzmeqEoGmcHBofsBAXd0HR6I2xhzipf5LJnVRqXDBwulxXJttNIC40ISY6g1FEtq 834V0jeO/+oyZl7pgwpjSvPkvwwlcHvAa50tMpCN76OA80BE/ve2CN7Zj/YgLryG83/D AsO34uhz1c4eOaRuepm+/loFZfdAOZqOiNC2Y/GxrWVptTLZ70XCGmfonsfA/Si3ipql BAaQ== X-Gm-Message-State: ALoCoQnZ6tFoo9/oTjygbJWEsgpb6EM3HdviRyIWARhRRhqNLwEiaGGY0U0x03UoeEAuyjrvHrsXAnAwYgq+cd4Dz3A7oKm8FKM1N62aSbUABVuDvLX4OQs= MIME-Version: 1.0 X-Received: by 10.182.20.115 with SMTP id m19mr3978491obe.22.1407189324306; Mon, 04 Aug 2014 14:55:24 -0700 (PDT) Received: by 10.182.218.51 with HTTP; Mon, 4 Aug 2014 14:55:24 -0700 (PDT) In-Reply-To: References: Date: Mon, 4 Aug 2014 14:55:24 -0700 Message-ID: Subject: Re: Performance on Widows vs *NIX From: Roshan Naik To: "user@flume.apache.org" Content-Type: multipart/alternative; boundary=001a11330c6eceb3e104ffd4cb74 X-Virus-Checked: Checked by ClamAV on apache.org --001a11330c6eceb3e104ffd4cb74 Content-Type: text/plain; charset=UTF-8 One of the hdfs compression codecs had a memory leak. dont recall which right now. if you are using one, try changing to a diff codec and see if the leak goes away. -roshan On Sat, Aug 2, 2014 at 6:19 AM, Christopher Shannon wrote: > I do want to add that the Windows agents in our configuration were > upstream from the agent using the HDFS sink, and the upstream agents would > not recover gracefully when the downstream agent disconnected them on > encountering an out of memory error. > > > On Sat, Aug 2, 2014 at 8:18 AM, Christopher Shannon > wrote: > >> Roshan, >> >> After more testing, it became plain that the Windows environment was not >> the problem. The simultaneous JVMs were behaving well in the Windows >> environment. There does appear to be a documented memory leak problem with >> the HDFS sink for version 1.3.0. Our distro comes from IBM BigInsights, and >> yes, there do appear to be some differences between some dependencies from >> the open source and what comes with the IBM distro. So we are looking into >> working with them to fix the problem. >> >> In the meantime, if you can think of any threads on the list pointing to >> HDFS sink and out of memory errors, I would be grateful if some can be sent >> my way. >> >> All the best, >> >> Chris. >> >> >> >> On Fri, Aug 1, 2014 at 6:50 PM, Roshan Naik >> wrote: >> >>> Is that a custom Flume build or from some distro ? Hard to say without >>> additional info. anything interesting in the logs when it crashes ? >>> >>> >>> On Tue, Jul 29, 2014 at 10:15 AM, Christopher Shannon < >>> cshannon108@gmail.com> wrote: >>> >>>> For development and testing, I sometimes have to run multiple agents on >>>> the same server / workstation. Recently I had to load test a second agent >>>> in a Windows environment with a near identical configuration (except for >>>> paths and more memory allocated to the JVM), but the agent in the second >>>> JVM soon ground to a halt whereas the first JVM with less memory worked >>>> without slowdown. >>>> >>>> The total physicsl memory on the machine is 32 gb, and the total >>>> physical RAM used never exceds 14GB. Disk space is plentiful. Agent A >>>> (started first) has a max JVM heap space of 4 gb, the second JVM (Agent B) >>>> has 8 gb allocated. Both use a spooling file source, a memory channel, and >>>> an Avro sink. >>>> >>>> Yet agent B is the one that slows down and evetually hangs. I have >>>> stood up multiple Flume agents on Linux without this problem. >>>> >>>> What could account for the degrading performance in a Windows >>>> environment for the second agent but not the first? >>>> >>>> All the best, Chris >>>> >>>> p.s. The agent version is 1.3.0, and I can't change it for contractual >>>> reasons. >>>> >>> >>> >>> CONFIDENTIALITY NOTICE >>> NOTICE: This message is intended for the use of the individual or entity >>> to which it is addressed and may contain information that is confidential, >>> privileged and exempt from disclosure under applicable law. If the reader >>> of this message is not the intended recipient, you are hereby notified that >>> any printing, copying, dissemination, distribution, disclosure or >>> forwarding of this communication is strictly prohibited. If you have >>> received this communication in error, please contact the sender immediately >>> and delete it from your system. Thank You. >> >> >> > -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You. --001a11330c6eceb3e104ffd4cb74 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
One of the hdfs compression codecs had a memory leak. dont= recall which right now. if you are using one, try changing to a diff codec= and see if the leak goes away.
-roshan


On Sat, Aug 2, 2014 at 6:19 AM, Christop= her Shannon <cshannon108@gmail.com> wrote:
I do want to add that the Windows agents in our configurat= ion were upstream from the agent using the HDFS sink, and the upstream agen= ts would not recover gracefully when the downstream agent disconnected them= on encountering an out of memory error.


On Sat, Aug 2= , 2014 at 8:18 AM, Christopher Shannon <cshannon108@gmail.com><= /span> wrote:
Roshan,

= After more testing, it became plain that the Windows environment was not th= e problem. The simultaneous JVMs were behaving well in the Windows environm= ent. There does appear to be a documented memory leak problem with the HDFS= sink for version 1.3.0. Our distro comes from IBM BigInsights, and yes, th= ere do appear to be some differences between some dependencies from the ope= n source and what comes with the IBM distro. So we are looking into working= with them to fix the problem.

In the meantime, if you can think of any threads on the= list pointing to HDFS sink and out of memory errors, I would be grateful i= f some can be sent my way.

All the best,

Chris.



On Fri, Aug 1, 2014 at = 6:50 PM, Roshan Naik <roshan@hortonworks.com> wrote:
Is that a custom Flume buil= d or from some distro ? Hard to say without additional info. anything inter= esting in =C2=A0the logs when it crashes ?


On = Tue, Jul 29, 2014 at 10:15 AM, Christopher Shannon <cshannon108@gmail.= com> wrote:

For development and testing, = I sometimes have to run multiple agents on the same server / workstation. R= ecently I had to load test a second agent in a Windows environment with a n= ear identical configuration (except for paths and more memory allocated to = the JVM), but the agent in the second JVM soon ground to a halt whereas the= first JVM with less memory worked without slowdown.

The total physicsl memory on the machine is 32 gb, and the t= otal physical RAM used never exceds 14GB. Disk space is plentiful. Agent A = (started first) has a max JVM heap space of 4 gb, the second JVM (Agent B) = has 8 gb allocated. Both use a spooling file source, a memory channel, and = an Avro sink.

Yet agent B is the one that slows down and evetually hangs. = I have stood up multiple Flume agents on Linux without this problem.

What could account for the degrading performance in a Window= s environment for the second agent but not the first?

All the best, Chris

p.s. The agent version is 1.3.0, and I can't change it f= or contractual reasons.



CONFIDENTIALITY NOTICE
NOTICE: This= message is intended for the use of the individual or entity to which it is= addressed and may contain information that is confidential, privileged and= exempt from disclosure under applicable law. If the reader of this message= is not the intended recipient, you are hereby notified that any printing, = copying, dissemination, distribution, disclosure or forwarding of this comm= unication is strictly prohibited. If you have received this communication i= n error, please contact the sender immediately and delete it from your syst= em. Thank You.




CONFIDENTIALITY NOTICE
NOTICE: This message is = intended for the use of the individual or entity to which it is addressed a= nd may contain information that is confidential, privileged and exempt from= disclosure under applicable law. If the reader of this message is not the = intended recipient, you are hereby notified that any printing, copying, dis= semination, distribution, disclosure or forwarding of this communication is= strictly prohibited. If you have received this communication in error, ple= ase contact the sender immediately and delete it from your system. Thank Yo= u. --001a11330c6eceb3e104ffd4cb74--