Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 22549200D19 for ; Fri, 6 Oct 2017 11:43:10 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 20F7C1609D0; Fri, 6 Oct 2017 09:43:10 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 498F1160BDC for ; Fri, 6 Oct 2017 11:43:09 +0200 (CEST) Received: (qmail 38168 invoked by uid 500); 6 Oct 2017 09:43:07 -0000 Mailing-List: contact issues-help@drill.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@drill.apache.org Delivered-To: mailing list issues@drill.apache.org Received: (qmail 38114 invoked by uid 99); 6 Oct 2017 09:43:07 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 06 Oct 2017 09:43:07 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 88212CBCDC for ; Fri, 6 Oct 2017 09:43:06 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -100.002 X-Spam-Level: X-Spam-Status: No, score=-100.002 tagged_above=-999 required=6.31 tests=[RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id H9ENYl_ehNIZ for ; Fri, 6 Oct 2017 09:43:05 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTP id 16A6A5FC3C for ; Fri, 6 Oct 2017 09:43:05 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 05933E0D4E for ; Fri, 6 Oct 2017 09:43:03 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id D36D024369 for ; Fri, 6 Oct 2017 09:43:00 +0000 (UTC) Date: Fri, 6 Oct 2017 09:43:00 +0000 (UTC) From: "ASF GitHub Bot (JIRA)" To: issues@drill.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (DRILL-5716) Queue-based memory assignment for buffering operators MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Fri, 06 Oct 2017 09:43:10 -0000 [ https://issues.apache.org/jira/browse/DRILL-5716?page=3Dcom.atlassian= .jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D1619= 4363#comment-16194363 ]=20 ASF GitHub Bot commented on DRILL-5716: --------------------------------------- Github user arina-ielchiieva commented on a diff in the pull request: https://github.com/apache/drill/pull/928#discussion_r143149580 =20 --- Diff: exec/java-exec/src/main/java/org/apache/drill/exec/work/forem= an/rm/AbstractResourceManager.java --- @@ -0,0 +1,68 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or imp= lied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ +package org.apache.drill.exec.work.foreman.rm; + +import org.apache.drill.common.config.DrillConfig; +import org.apache.drill.exec.ExecConstants; +import org.apache.drill.exec.server.DrillbitContext; + +/** + * Abstract base class for a resource manager. Handles tasks common to= all + * resource managers: learning the resources available on this Drillbi= t. + * In the current version, Drillbits must be symmetrical, so that know= ing + * the resources on one node is sufficient to know resources available= on + * all nodes. + */ + +public abstract class AbstractResourceManager implements ResourceManag= er { + + protected final DrillbitContext context; + private final long memoryPerNode; + private final int cpusPerNode; + + public AbstractResourceManager(final DrillbitContext context) { + this.context =3D context; + DrillConfig config =3D context.getConfig(); + + // Normally we use the actual direct memory configured on the JVM = command + // line. However, if the config param is set, we use that instead = (if it is + // lower than actual memory). Primarily for testing. + + long memLimit =3D DrillConfig.getMaxDirectMemory(); + long configMemoryPerNode =3D config.getBytes(ExecConstants.MAX_MEM= ORY_PER_NODE); --- End diff -- =20 Nice, thanks for explanation. > Queue-based memory assignment for buffering operators > ----------------------------------------------------- > > Key: DRILL-5716 > URL: https://issues.apache.org/jira/browse/DRILL-5716 > Project: Apache Drill > Issue Type: Improvement > Affects Versions: 1.11.0 > Reporter: Paul Rogers > Assignee: Paul Rogers > Labels: doc-impacting > Fix For: 1.12.0 > > > Apache Drill already has a queueing feature based on ZK semaphores. We di= d a bit of testing to show that the feature does, in fact work. We propose= to enhance the feature with some light revisions to make work with the "ma= naged" external sort and the newly-added spilling feature for the hash agg = operator. The key requirement is to build on what we have for now; we may w= ant to tackle a larger project to create a more complete solution later. > Existing functionality: > * Two ZK-based queues called the =E2=80=9Csmall=E2=80=9D and =E2=80=9Clar= ge=E2=80=9D query queues. > * A threshold, call it T, given as a query cost, to determine the queue i= nto which a query will go. > * Admit levels for the two queues: call them Qs and Ql. > Basically, when a query comes in: > * Plan the query as usual. > * Obtain the final query cost from the planner, call this C. > * If C * Suppose the small queue. Ask ZK if the query can run. > * ZK checks if Qs queries are already running. If so, the query waits, el= se the query runs. > The proposed changes include: > * Refactor the code to provide a queueing API that supports a variety of = queuing mechanisms. > * Provide three: the null queue (default), an in-process queue (for testi= ng) and the ZK queues. > * Modify the query profile web UI to show two new bits of information abo= ut queues: > - The queue to which the query was sent. > - The total planning cost. > * Modify the query profile web UI to show two memory assignment numbers: > - Total memory allocated to the query > - Memory per sort or hash-add operator > Then, add to the queue mechanism the ability to do memory assignment: > * Provide a weight, W: every small query gets 1 unit, every large query g= ets W units. > * Use the queue admit levels to determine total units: U =3D Qs + W * Ql. > * Obtain total direct memory from the system. M. > * Subtract a reserve percent R for overhead. > * Do the math to get the memory per query for each query: > * For the small queue: (M - R) / U > * For the large queue: (M - R) / U * W > * Use this memory amount as the =E2=80=9Cmemory per query=E2=80=9D number= in the existing sort/hash-agg memory assignment (instead of the fixed 2 GB= .) > The result will be a nice incremental addition to what we already have, a= nd should make it a bit easier people to actually use the feature (because = they can see the planning numbers and see the queues used, allowing them to= effectively tune the system.) > The API used for the above features also allow third parties to add on a = more robust admission control feature as needed, perhaps tying into an exis= ting queueing mechanism of their choice. -- This message was sent by Atlassian JIRA (v6.4.14#64029)