Return-Path: X-Original-To: apmail-hadoop-mapreduce-user-archive@minotaur.apache.org Delivered-To: apmail-hadoop-mapreduce-user-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id B00FE113D2 for ; Fri, 1 Aug 2014 09:41:40 +0000 (UTC) Received: (qmail 80933 invoked by uid 500); 1 Aug 2014 09:41:31 -0000 Delivered-To: apmail-hadoop-mapreduce-user-archive@hadoop.apache.org Received: (qmail 80810 invoked by uid 500); 1 Aug 2014 09:41:31 -0000 Mailing-List: contact user-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@hadoop.apache.org Delivered-To: mailing list user@hadoop.apache.org Received: (qmail 80793 invoked by uid 99); 1 Aug 2014 09:41:31 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Aug 2014 09:41:31 +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 julnaour@gmail.com designates 209.85.218.43 as permitted sender) Received: from [209.85.218.43] (HELO mail-oi0-f43.google.com) (209.85.218.43) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Aug 2014 09:41:25 +0000 Received: by mail-oi0-f43.google.com with SMTP id u20so2612895oif.30 for ; Fri, 01 Aug 2014 02:41:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=q/QqxtrW4/DoiGhTpQ+RO5aB2OcKUew+oTEH3F3MxVk=; b=tEoO4EiJFzJ0lgaXkd++mdzzaKP8gdxbz+mQRIdFpIoz6V6qFGIerTSt4WxalD1hcf wRVjUGdAyWYySqBfyKfKLjv9NEBjG3OnVsUJtUub0nKODWZd2MesMW0OOe6FvdVD3zE2 92+H5xCnrDWKDXfC68+Oqm333jSQI5hHgImUuNN3Mj3dQrPrKfvmMMttfsajEVEIBc/7 gUjheuQ9j3zjWMvOdRj92tKAPIm+L9lfpiqMd9czh7EZ3d6hyqzpRl9oYGf/CnU8cABB 61R1c2TPZTfUbYL5ZlygrGLBh/l7xacbOuvoj+jmsn2bbGmGGtJEPspjR+rtnjBtUY6P qHAQ== MIME-Version: 1.0 X-Received: by 10.60.103.50 with SMTP id ft18mr3878467oeb.47.1406886065083; Fri, 01 Aug 2014 02:41:05 -0700 (PDT) Received: by 10.76.113.84 with HTTP; Fri, 1 Aug 2014 02:41:05 -0700 (PDT) Date: Fri, 1 Aug 2014 11:41:05 +0200 Message-ID: Subject: Fair Scheduler issue From: Julien Naour To: user@hadoop.apache.org Content-Type: multipart/alternative; boundary=089e0116060226192604ff8e3004 X-Virus-Checked: Checked by ClamAV on apache.org --089e0116060226192604ff8e3004 Content-Type: text/plain; charset=UTF-8 Hello, I'm currently using HDP 2.0 so it's Hadoop 2.2.0. My cluster consist in 4 nodes, 16 coeurs 16 GB RAM 4*3To each. Recently we passed from 2 users to 8. We need now a more appropriate Scheduler. We begin with Capacity Scheduler. There was some issues with the different queues particularly when using some spark shell that used some resources for a long time. So we decide to try Fair Scheduler which seems to be a good solution. The problem is that FairScheduler doesn't allow all available resources. It's capped at 73% of the available memory for one jobs 63% for 2 jobs and 45% for 3 jobs. The problem could come from shells that take resources for a long time. We tried some configuration like yarn.scheduler.fair.user-as-default-queue=false or play with the minimum ressources allocated minResources in fair-scheduler.xml but it doesn't seems to resolve the issue. Any advices or good practices to held a good Fair Scheduler? Regards, Julien --089e0116060226192604ff8e3004 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

I'm currently using HDP 2.0 = so it's Hadoop 2.2.0.
My cluster consist in 4 nodes, 16 coeur= s 16 GB RAM 4*3To each.

Recently we passed from 2 = users to 8. We need now a more appropriate Scheduler.
We begin with Capacity Scheduler. There was some issues with the diffe= rent queues particularly when using some spark shell that used some resourc= es for a long time.
So we decide to try Fair Scheduler which seem= s to be a good solution.
The problem is that FairScheduler doesn't allow all available reso= urces. It's capped at 73% of the available memory for one jobs 63% for = 2 jobs and 45% for 3 jobs. The problem could come from shells that take res= ources for a long time.

We tried some configuration like =C2=A0yarn.scheduler.fai= r.user-as-default-queue=3Dfalse
or play with the minimum r= essources allocated minResources in fair-scheduler.xml but it doesn't s= eems to resolve the issue.

Any advices or good practices to held a good Fair= Scheduler?

Regards,

Juli= en
--089e0116060226192604ff8e3004--