Return-Path: X-Original-To: apmail-giraph-user-archive@www.apache.org Delivered-To: apmail-giraph-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 3DB19105C9 for ; Fri, 18 Oct 2013 17:32:06 +0000 (UTC) Received: (qmail 71370 invoked by uid 500); 18 Oct 2013 17:32:05 -0000 Delivered-To: apmail-giraph-user-archive@giraph.apache.org Received: (qmail 71336 invoked by uid 500); 18 Oct 2013 17:32:05 -0000 Mailing-List: contact user-help@giraph.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@giraph.apache.org Delivered-To: mailing list user@giraph.apache.org Received: (qmail 71321 invoked by uid 99); 18 Oct 2013 17:32:04 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 18 Oct 2013 17:32:04 +0000 X-ASF-Spam-Status: No, hits=0.8 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS,TO_NO_BRKTS_PCNT X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of ssc.open@googlemail.com designates 74.125.83.41 as permitted sender) Received: from [74.125.83.41] (HELO mail-ee0-f41.google.com) (74.125.83.41) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 18 Oct 2013 17:31:52 +0000 Received: by mail-ee0-f41.google.com with SMTP id b15so1784775eek.0 for ; Fri, 18 Oct 2013 10:31:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=/1PMiDDQgXYyr63yYhtNZPnrd2dcwCJInfWAvgl2i10=; b=Mw7S9ynC7YS2PLIO0hydxBrlOs14s/Vk4nv/Jc7Y26OdiXJ00vKk0hLnnx8tuq0fot PvrL+y5mwulqh3aemI1tObC9PvcYZBBX7UUyoqHuQgbFKuAXF64HyUvt4IQ7uHR5yoNM cRMy4iJu7YMTueFB2QsG4iYvKUUPf4/syX5RQNTpEIDx1T+iZvXFXNWrOfTUd7gkXYh0 w5hxq15Bk25O7vY1hhLh9rypnc9tN2/HWeFQwloa47T+aqbR8ErdnsF1cygr3yc81/O4 V258EkrW8utDIp93zMWJ+VharOrWF3p9u9KxBXl41DmX75WxSArftsD8vmW1ZpnG2soG Qt3Q== X-Received: by 10.15.90.132 with SMTP id q4mr4294729eez.98.1382117490855; Fri, 18 Oct 2013 10:31:30 -0700 (PDT) Received: from [192.168.0.110] (f052149149.adsl.alicedsl.de. [78.52.149.149]) by mx.google.com with ESMTPSA id k7sm7027619eeg.13.2013.10.18.10.31.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Oct 2013 10:31:30 -0700 (PDT) Message-ID: <52617071.7070304@apache.org> Date: Fri, 18 Oct 2013 19:31:29 +0200 From: Sebastian Schelter Reply-To: ssc@apache.org User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130330 Thunderbird/17.0.5 MIME-Version: 1.0 To: user@giraph.apache.org Subject: Re: How to specify parameters in order to run giraph job in parallel References: <1724.219.79.190.64.1382116356.squirrel@sqmail.ust.hk> <1899.219.79.190.64.1382117286.squirrel@sqmail.ust.hk> In-Reply-To: <1899.219.79.190.64.1382117286.squirrel@sqmail.ust.hk> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org Da, Holding objects in serialized form as bytes in byte arrays consumes much less memory than holding them as Java objects (which have a huge overhead), I think that is the other main reason for serialization. --sebastian On 18.10.2013 19:28, YAN Da wrote: > Dear Claudio Martella, > > According to https://reviews.apache.org/r/7990/diff/?page=2, Giraph > currently organize vertices as byte streams, probabily pages. > > In the url, "This also significantly reduces GC time, as there are less > objects to GC." > > Why there's "also" there? I mean, is reducing GC time the only reason for > doing serialization? > > Regards, > Da > >> Dear Claudio Martella, >> >> I don't quite get what you mean. Our cluster has 15 servers each with 24 >> cores, so ideally there can be 15*24 threads/partitions work in parallel, >> right? (Perhaps deduct one for ZooKeeper) >> >> However, when we set the "-Dgiraph.numComputeThreads" option, we find that >> we cannot have even 20 threads, and when set to 10, the CPU usage is just >> a little bit doubles that of the default setting, not anything close to >> 100*numComputeThreads%. >> >> How can we set it to work on our server to utilize all the processors? >> >> Regards, >> Da Yan >> >>> It actually depends on the setup of your cluster. >>> >>> Ideally, with 15 nodes (tasktrackers) you'd want 1 mapper slot per node >>> (ideally to run giraph), so that you would have 14 workers, one per >>> computing node, plus one for master+zookeeper. Once that is reached, you >>> would have a number of compute threads equals to the number of threads >>> that >>> you can run on each node (24 in your case). >>> >>> Does this make sense to you? >>> >>> >>> On Thu, Oct 17, 2013 at 5:04 PM, Yi Lu wrote: >>> >>>> Hi, >>>> >>>> I have a computer cluster consisting of 15 slave machines and 1 master >>>> machine. >>>> >>>> On each slave machine, there are two Xeon E5-2620 CPUs. With the help >>>> of >>>> HT, there are 24 threads. >>>> >>>> I am wondering how to specify parameters in order to run giraph job in >>>> parallel on my cluster. >>>> >>>> I am using the following parameters to run a pagerank algorithm. >>>> >>>> hadoop jar ~/giraph-examples.jar org.apache.giraph.GiraphRunner >>>> SimplePageRank -vif PageRankInputFormat -vip /input -vof >>>> PageRankOutputFormat -op /pagerank -w 1 -mc >>>> SimplePageRank\$SimplePageRankMasterCompute -wc >>>> SimplePageRank\$SimplePageRankWorkerContext >>>> >>>> In particular, >>>> >>>> 1)I know I can use “-w” to specify the number of workers. In my >>>> opinion, >>>> the number of workers equals to the number of mappers in hadoop except >>>> zookeeper. Therefore, in my case(15 slave machine), which number should >>>> be >>>> chosen? Is 15 a good choice? Since, I find if I input a large number, >>>> e.g. >>>> 100, the mappers will hang. >>>> >>>> 2)I know I can use “-Dgiraph.numComputeThreads=1” to specify vertex >>>> computing thread number. However, if I specify it to 10, the total >>>> runtime >>>> is much longer than default. I think the default is 1, which is found >>>> in >>>> the source code. I wonder if I want to use this parameter, which number >>>> should be chosen. >>>> >>>> 3)When the giraph job is running, I use “top” command to monitor my cpu >>>> usage on slave machines. I find that the java process can use 200%-300% >>>> cpu >>>> resource. However, if I change the number of vertex computing threads >>>> to >>>> 10, the java process can use 800% cpu resource. I think it is not a >>>> linear >>>> relation and I want to know why. >>>> >>>> >>>> Thanks for your help. >>>> >>>> Best, >>>> >>>> -Yi >>>> >>> >>> >>> >>> -- >>> Claudio Martella >>> claudio.martella@gmail.com >>> >> >> >> > > > >