Return-Path: Delivered-To: apmail-hadoop-hdfs-user-archive@minotaur.apache.org Received: (qmail 61281 invoked from network); 23 Jan 2010 20:51:27 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 23 Jan 2010 20:51:27 -0000 Received: (qmail 22169 invoked by uid 500); 23 Jan 2010 20:51:27 -0000 Delivered-To: apmail-hadoop-hdfs-user-archive@hadoop.apache.org Received: (qmail 22080 invoked by uid 500); 23 Jan 2010 20:51:26 -0000 Mailing-List: contact hdfs-user-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: hdfs-user@hadoop.apache.org Delivered-To: mailing list hdfs-user@hadoop.apache.org Received: (qmail 22070 invoked by uid 99); 23 Jan 2010 20:51:26 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 23 Jan 2010 20:51:26 +0000 X-ASF-Spam-Status: No, hits=-1.8 required=10.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [85.158.136.211] (HELO mail157.messagelabs.com) (85.158.136.211) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 23 Jan 2010 20:51:16 +0000 X-VirusChecked: Checked X-Env-Sender: Zlatin.Balevsky@barclayscapital.com X-Msg-Ref: server-11.tower-157.messagelabs.com!1264279852!13061589!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [146.127.253.25] Received: (qmail 31277 invoked from network); 23 Jan 2010 20:50:53 -0000 Received: from unknown (HELO mx24.barcap.com) (146.127.253.25) by server-11.tower-157.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 23 Jan 2010 20:50:53 -0000 Received: from nykpsmeg0000001.INTRANET.BARCAPINT.COM (nykpsmeg0000001.nyk.mess.barcap.com [10.54.16.1]) by mx24.barcap.com (Postfix) with ESMTP id 10E4897002C for ; Sat, 23 Jan 2010 15:18:50 -0500 (EST) Received: from nykpsmmgch06.INTRANET.BARCAPINT.COM (Not Verified[10.58.21.30]) by nykpsmeg0000001.INTRANET.BARCAPINT.COM with Barclays Capital Filter ESMTP id ; Sat, 23 Jan 2010 15:50:51 -0500 Received: from NYKPCMMGMB07.INTRANET.BARCAPINT.COM ([169.254.1.208]) by nykpsmmgch06.INTRANET.BARCAPINT.COM ([10.58.21.30]) with mapi; Sat, 23 Jan 2010 15:50:51 -0500 From: To: Date: Sat, 23 Jan 2010 15:50:50 -0500 Subject: RE: Exponential performance decay - mystery solved Thread-Topic: Exponential performance decay - mystery solved Thread-Index: Acqa+Jiny57J38hLTiO5ZU3YXKW+zQBdPCmQ Message-ID: References: <0415D0186561FD448D99C301257B70910120BA46@NYKPCMEU304VEUA.INTRANET.BARCAPINT.COM> <45f85f71001140947n3d7dcdc2s775c40aadc82ed77@mail.gmail.com> <0415D0186561FD448D99C301257B70910120BA4E@NYKPCMEU304VEUA.INTRANET.BARCAPINT.COM> <0415D0186561FD448D99C301257B70910120BA50@NYKPCMEU304VEUA.INTRANET.BARCAPINT.COM> <0415D0186561FD448D99C301257B70910120BA51@NYKPCMEU304VEUA.INTRANET.BARCAPINT.COM> <0415D0186561FD448D99C301257B70910120BA56@NYKPCMEU304VEUA.INTRANET.BARCAPINT.COM> <0415D0186561FD448D99C301257B70910120BA6D@NYKPCMEU304VEUA.INTRANET.BARCAPINT.COM> <20d6e77d1001211619r2e7aa313m2c757cad6887d649@mail.gmail.com> In-Reply-To: <20d6e77d1001211619r2e7aa313m2c757cad6887d649@mail.gmail.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_BE12EA469D2AF24A8795C59FA147EE8A2186140CNYKPCMMGMB07INT_" MIME-Version: 1.0 --_000_BE12EA469D2AF24A8795C59FA147EE8A2186140CNYKPCMMGMB07INT_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Happy to report this doesn't happen with 0.21 even with block report interv= al of 30 seconds. Zlatin ________________________________ From: Raghu Angadi [mailto:rangadi@apache.org] Sent: Thursday, January 21, 2010 7:19 PM To: hdfs-user@hadoop.apache.org Subject: Re: Exponential performance decay - mystery solved http://issues.apache.org/jira/browse/HADOOP-4584 is supposed to fix this ex= act problem with the block reports. Were you running 0.21 or 0.20? Raghu. On Thu, Jan 21, 2010 at 11:41 AM, > wrote: Alright, the problem was caused by me setting the frequency of a block report to 30 seconds. The idea behind that was to create more load on the Namenode, but I didn't notice that those block reports were taking increasing amounts of time to generate. During that time, a lock was held which I'm guessing didn't allow the reporting datanode to perform its functions. On my hardware, with 100,000 blocks the report takes over 7 seconds. So every datanode was unavailable for 7 out of every 30 seconds. Changing the interval to a more reasonable value restored the insertion speed to linear. Apologies for creating this confusion, nevertheless it was a useful thing to learn. Regards, Zlatin -----Original Message----- From: Eli Collins [mailto:eli@cloudera.com] Sent: Thursday, January 21, 2010 2:02 PM To: hdfs-user@hadoop.apache.org Subject: Re: Exponential performance decay - possible lead > > The messages are of the following: > > 2010-01-18 14:51:25,694 WARN org.apache.hadoop.hdfs.StateChange: > BLOCK* NameSystem.addStoredBlock: Redundant addStoredBlock request > received for blk_-5804440919363539694_1026 on ip.removed:port.removed > size 1024 This is odd, you should't be getting this warning, I don't see it when running your benchmark on my cluster. Are there other relevant/warnings errors in the NN or DN logs? Thanks, Eli _______________________________________________ This e-mail may contain information that is confidential, privileged or oth= erwise protected from disclosure. If you are not an intended recipient of t= his e-mail, do not duplicate or redistribute it by any means. Please delete= it and any attachments and notify the sender that you have received it in = error. Unless specifically indicated, this e-mail is not an offer to buy or= sell or a solicitation to buy or sell any securities, investment products = or other financial product or service, an official confirmation of any tran= saction, or an official statement of Barclays. Any views or opinions presen= ted are solely those of the author and do not necessarily represent those o= f Barclays. This e-mail is subject to terms available at the following link= : www.barcap.com/emaildisclaimer. By= messaging with Barclays you consent to the foregoing. Barclays Capital is= the investment banking division of Barclays Bank PLC, a company registered= in England (number 1026167) with its registered office at 1 Churchill Plac= e, London, E14 5HP. This email may relate to or be sent from other members= of the Barclays Group. _______________________________________________ --_000_BE12EA469D2AF24A8795C59FA147EE8A2186140CNYKPCMMGMB07INT_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Happy to report this doesn't happen with 0.21 even= with=20 block report interval of 30 seconds.
 
Zlatin


From: Raghu Angadi [mailto:rangadi@apac= he.org]=20
Sent: Thursday, January 21, 2010 7:19 PM
To:=20 hdfs-user@hadoop.apache.org
Subject: Re: Exponential performance = decay=20 - mystery solved


http://issues.apache.org/jira/browse/HADOOP-4584 is sup= posed=20 to fix this exact problem with the block reports. Were you running 0.21 or= =20 0.20?

Raghu.


On Thu, Jan 21, 2010 at 11:41 AM, = <Zlatin.Balevsky@barclay= scapital.com>=20 wrote:


Alright,=20 the problem was caused by me setting the frequency of a block
report t= o 30=20 seconds.  The idea behind that was to create more load on
the=20 Namenode, but I didn't notice that those block reports were=20 taking
increasing amounts of time to generate.  During that time,= a=20 lock was
held which I'm guessing didn't allow the reporting datanode t= o=20 perform
its functions.

On my hardware, with 100,000 blocks the= =20 report takes over 7 seconds.  So
every datanode was unavailable f= or 7=20 out of every 30 seconds.  Changing
the interval to a more reasona= ble=20 value restored the insertion speed to
linear.

Apologies for cre= ating=20 this confusion, nevertheless it was a useful
thing to=20 learn.

Regards,
Zlatin

-----Original Message-----
Fro= m:=20 Eli Collins [mailto:eli@cloudera.com]
Sent: Thursday,= =20 January 21, 2010 2:02 PM
To: hdfs-user@hadoop.apache.org
Subject:=20 Re: Exponential performance decay - possible lead

>
> The= =20 messages are of the following:
>
> 2010-01-18 14:51:25,694 WA= RN=20 org.apache.hadoop.hdfs.StateChange:
> BLOCK* NameSystem.addStoredBl= ock:=20 Redundant addStoredBlock request
> received for=20 blk_-5804440919363539694_1026 on ip.removed:port.removed
> size=20 1024

This is odd, you should't be getting this warning, I don't se= e it=20 when
running your benchmark on my cluster. Are there other=20 relevant/warnings
errors in the NN or DN=20 logs?

Thanks,
Eli
__________________________________________= _____

This=20 e-mail may contain information that is confidential, privileged or otherw= ise=20 protected from disclosure. If you are not an intended recipient of this=20 e-mail, do not duplicate or redistribute it by any means. Please delete i= t and=20 any attachments and notify the sender that you have received it in error.= =20 Unless specifically indicated, this e-mail is not an offer to buy or sell= or a=20 solicitation to buy or sell any securities, investment products or other= =20 financial product or service, an official confirmation of any transaction= , or=20 an official statement of Barclays. Any views or opinions presented are so= lely=20 those of the author and do not necessarily represent those of Barclays. T= his=20 e-mail is subject to terms available at the following link: www.barcap.com/emaildisclaimer. By messaging with Bar= clays=20 you consent to the foregoing.  Barclays Capital is the investment ba= nking=20 division of Barclays Bank PLC, a company registered in England (number=20 1026167) with its registered office at 1 Churchill Place, London, E14 5HP= .=20  This email may relate to or be sent from other members of the Barcl= ays=20 Group.
_______________________________________________

--_000_BE12EA469D2AF24A8795C59FA147EE8A2186140CNYKPCMMGMB07INT_--