Mailing-List: contact user-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@hadoop.apache.org
Received-SPF: pass (athena.apache.org: domain of harsh@cloudera.com designates
 209.85.223.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAK_MoSsZK8UxWvZohz0wWTZ83haT=mbKtFkd6GEcExd=yiRpbg@mail.gmail.com>
References: 
 <CAK_MoSvmz4+FPjb6S9PGTTWEBvhAswgkMuJSvJ40wJT+BGLQFg@mail.gmail.com>
 <491FA550-FC92-4280-8FB5-186E5F7A4743@123.org>
 <CAK_MoSuY1B5P_AQTzJfrAwB_-tJ0gmt2PvTaBR9qG5bjPHDpEg@mail.gmail.com>
 <A06694F8-AFA7-49C3-81DC-F3C1B10E47C3@123.org>
 <CAK_MoSsZK8UxWvZohz0wWTZ83haT=mbKtFkd6GEcExd=yiRpbg@mail.gmail.com>
From: Harsh J <harsh@cloudera.com>
Date: Wed, 26 Dec 2012 14:21:48 +0530
Message-ID: 
 <CAOcnVr0d7F2YesEjyh92zFF0yb6r-j3_uQoS6wi6C3jdvz2yig@mail.gmail.com>
Subject: Re: distributed cache
To: "<user@hadoop.apache.org>" <user@hadoop.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

Hi Lin,

DistributedCache files are stored onto the HDFS by the client first.
The TaskTrackers download and localize it. Therefore, as with any
other file on HDFS, "downloads" can be efficiently parallel with
higher replicas.

The point of having higher replication for these files is also tied to
the concept of racks in a cluster - you would want more replicas
spread across racks such that on task bootup the downloads happen with
rack locality.

On Sat, Dec 22, 2012 at 6:54 PM, Lin Ma <linlma@gmail.com> wrote:
> Hi Kai,
>
> Smart answer! :-)
>
> The assumption you have is one distributed cache replica could only serve
> one download session for tasktracker node (this is why you get concurrency
> n/r). The question is, why one distributed cache replica cannot serve
> multiple concurrent download session? For example, supposing a tasktracker
> use elapsed time t to download a file from a specific distributed cache
> replica, it is possible for 2 tasktrackers to download from the specific
> distributed cache replica in parallel using elapsed time t as well, or 1.5
> t, which is faster than sequential download time 2t you mentioned before?
> "In total, r+n/r concurrent operations. If you optimize r depending on n,
> SRQT(n) is the optimal replication level." -- how do you get SRQT(n) for
> minimize r+n/r? Appreciate if you could point me to more details.
>
> regards,
> Lin
>
>
> On Sat, Dec 22, 2012 at 8:51 PM, Kai Voigt <k@123.org> wrote:
>>
>> Hi,
>>
>> simple math. Assuming you have n TaskTrackers in your cluster that will
>> need to access the files in the distributed cache. And r is the replication
>> level of those files.
>>
>> Copying the files into HDFS requires r copy operations over the network.
>> The n TaskTrackers need to get their local copies from HDFS, so the n
>> TaskTrackers copy from r DataNodes, so n/r concurrent operation. In total,
>> r+n/r concurrent operations. If you optimize r depending on n, SRQT(n) is
>> the optimal replication level. So 10 is a reasonable default setting for
>> most clusters that are not 500+ nodes big.
>>
>> Kai
>>
>> Am 22.12.2012 um 13:46 schrieb Lin Ma <linlma@gmail.com>:
>>
>> Thanks Kai, using higher replication count for the purpose of?
>>
>> regards,
>> Lin
>>
>> On Sat, Dec 22, 2012 at 8:44 PM, Kai Voigt <k@123.org> wrote:
>>>
>>> Hi,
>>>
>>> Am 22.12.2012 um 13:03 schrieb Lin Ma <linlma@gmail.com>:
>>>
>>> > I want to confirm when on each task node either mapper or reducer
>>> > access distributed cache file, it resides on disk, not resides in memory.
>>> > Just want to make sure distributed cache file does not fully loaded into
>>> > memory which compete memory consumption with mapper/reducer tasks. Is that
>>> > correct?
>>>
>>>
>>> Yes, you are correct. The JobTracker will put files for the distributed
>>> cache into HDFS with a higher replication count (10 by default). Whenever a
>>> TaskTracker needs those files for a task it is launching locally, it will
>>> fetch a copy to its local disk. So it won't need to do this again for future
>>> tasks on this node. After a job is done, all local copies and the HDFS
>>> copies of files in the distributed cache are cleaned up.
>>>
>>> Kai
>>>
>>> --
>>> Kai Voigt
>>> k@123.org
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Kai Voigt
>> k@123.org
>>
>>
>>
>>
>


-- 
Harsh J