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 C2941200C58 for ; Sun, 16 Apr 2017 12:15:09 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id C1069160B9A; Sun, 16 Apr 2017 10:15:09 +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 BA561160B92 for ; Sun, 16 Apr 2017 12:15:08 +0200 (CEST) Received: (qmail 95077 invoked by uid 500); 16 Apr 2017 10:15:07 -0000 Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@hbase.apache.org Delivered-To: mailing list dev@hbase.apache.org Received: (qmail 95065 invoked by uid 99); 16 Apr 2017 10:15:06 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 16 Apr 2017 10:15:06 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id C919FC05AA for ; Sun, 16 Apr 2017 10:15:05 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -0.397 X-Spam-Level: X-Spam-Status: No, score=-0.397 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id lOPRmPGTyhSc for ; Sun, 16 Apr 2017 10:15:03 +0000 (UTC) Received: from mail-io0-f176.google.com (mail-io0-f176.google.com [209.85.223.176]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 3FCFD5F1E7 for ; Sun, 16 Apr 2017 10:15:01 +0000 (UTC) Received: by mail-io0-f176.google.com with SMTP id a103so131843465ioj.1 for ; Sun, 16 Apr 2017 03:15:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=3X0aiieYMRTCniX5VYw+Fvfxz+CgSP6mo83Q557pqM8=; b=MgRS8iatSQGLl9ghcGqHeOb9ZjSW4cRI2X2CbF0EdaO5GFbnSFB+hnSITUfhE3SH0S sr0Gub7WytwQIRFGBdHtplFwPti9BQiXKU+CeVBiwqYfx6ds9v4CsezzZ0crGOFRARWh drPc1T4n77oVf1gmRygVQStmuQnkOpsxkTcKmL310hEIS8VFnIdxF70FgRdAFH1z7GIk IuA8yhiSeclBgXxv3Q74JN8zha6HU2PFKF0iD4gMkQKxavnHo5vnirUnTTEoTQmeX7/w 4HqVigi57e0sxTc9R0/Uvz+GNnPiImGQFBXuPRnASJiCwqVhDwjKR1n024as+egj/Kvv 58ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=3X0aiieYMRTCniX5VYw+Fvfxz+CgSP6mo83Q557pqM8=; b=Ddyv/2p7gMtNLcF5cGTQhAQlzpUSAqlMyE2Hb1+2szbyjhAB6/0ZXqpdoR9fZBDNG5 FRx3BSpAOBYh50hVe7JvPCVQQfbHuYCXkOXoKcjk1rEoaKy5VBiyDFadU1pHUpPObKuY DDOmJCO1JAZmxl3fCXkFz16jfILloU5tXApVjbDnfJQXK5iGDHwNKZWWc0ycU0uImob/ UMY+uEHC7RLE1HeJj/9KNJ/rDyF1cKBnb2R43CMti8iNR0T5MjIWmQuJkj6dIWTqZw2g BxJzZrlmJYewtVTizO7s6U8xLwQI2jnJupM2FRIgWp8yElrad2JZtRTOqQZ0mUiHUSNm UroQ== X-Gm-Message-State: AN3rC/6Vf9fEO+2xc3pAeSe0EO7PuuKyGn+a931Gf0jkh6TGpFiCZrNv kXFmW62wAI8xP5qDZCpt1hPqPpwJ1vu4 X-Received: by 10.107.6.224 with SMTP id f93mr5014646ioi.210.1492337694874; Sun, 16 Apr 2017 03:14:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.87 with HTTP; Sun, 16 Apr 2017 03:14:54 -0700 (PDT) In-Reply-To: References: From: libis Date: Sun, 16 Apr 2017 18:14:54 +0800 Message-ID: Subject: Re: A new Mutilple-Type Queue idea to handle multiple workloads To: dev@hbase.apache.org Content-Type: multipart/related; boundary=001a113fb63230ba05054d45f24f archived-at: Sun, 16 Apr 2017 10:15:09 -0000 --001a113fb63230ba05054d45f24f Content-Type: multipart/alternative; boundary=001a113fb63230ba02054d45f24e --001a113fb63230ba02054d45f24e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I am runing expriment at the following scenario : both client-1 and client-2 send update requests, the client-1 write the large objects(100KB record) into table-1, and client-2 write the small objects (1KB record) into table-2. The charts below shows the effect of the Mutilple-Type queue feature: [image: =E5=86=85=E5=B5=8C=E5=9B=BE=E7=89=87 1] as shown in future 1(the default version of hbase 1.1.2): 1. in the beginning, client-2 starts to sends requests and client-1 not. the throughput of client-2 keep stable 2. when client-1 starts, the throughputs of both client-1 and client-2 are very unstable, that is to say client-1 influence client-2 seriously 3. the average hbase throughput is 36641 . [image: =E5=86=85=E5=B5=8C=E5=9B=BE=E7=89=87 4] Afterwords, we assign 150 handlers to table-2 and 3 handlers to table-1 with mutilple-type queue feature. as shown in future 2, the throughputs of both client-1 and client-2 are more smooth, the average hbase throughput is 51653 , 41% higher. so we think in some cases the feature is a improvement for running multiple workloads on a single hbase cluster, let me know if anything is incorrect or inaccurate . Thanks a lot for your help! 2017-04-11 13:58 GMT+08:00 =E8=8C=83=E8=8C=83=E6=AC=A3=E6=AC=A3 : > Now, the feature HBASE-11355 seperates the single Call Queue into > MutilQueue(get call queue, write call queue and scan call queue), and eac= h > type queue can specify fixed number of handlers. It's helpful in some > outages , to avoid all read or all write requests ran out of handler > threads. > > however, there are still several problems : > > 1. workloads in the same request type(get/write/scan) may influence each > other as before, consider the following scenario: > > (1) both client-1 and client-2 send write requests, the client-1 write th= e > large objects(100KB record) , and client-2 write the small objects (1KB > record). the client -1 will ran out of all handler threads of the > write-queue, and decrease the client-2 throughput > > (2) both client-3 and client-4 send get requests, the client-3 search all > data from lots of hfiles( all search key are equally popular), read laten= cy > is high. the client-4 do not require any I/O resources(say, data is > cached). the client-3 will ran out of all handler threads of the get-queu= e, > and increase the read latency of client-4 > > 2. administor can't increate/decrease the handler number for the specifie= d > queue easily > > > we are trying to implement a new Mutilple-Typed Queue, administor can > create a queue with a specified number of handler for specified table and > specified request type(get/write/scan), as: > > create_queue 'queue1' ,{'handler' =3D> 100} > > grant_queue 'table1','scan','queue1' > > grant_queue 'tableN','scan','queue1' > > > create_queue 'queue2' ,{'handler' =3D> 50} > > grant_queue 'table2','write','queue2' > > > the idea based on the fact that the workload for a specified table and > request type will be unique. > > in addition, administor can manager the queue with commands: > > //easily increase/decrease handlers > > alter_queue 'queue1' ,{'handler' =3D> 50} > > //list all queues > > list_queues > > //drop the specified queue > > drop_queue 'queue1' > > > I am wondering if the developers could look at the idea and let me know i= f > anything is incorrect or inaccurate, or if I have missed anything. > > > Thanks a lot for your help! > --001a113fb63230ba02054d45f24e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I am runing expriment at the following= scenario : both client-1 and client-2 send update requests, the client-1 w= rite the large objects(100KB record) into table-1, and client-2 write the s= mall objects (1KB record) into table-2. The charts below shows the effect o= f the Mutilple-Type queue feature:=C2=A0

3D"=E5=86=85=E5=B5=8C=

as shown in future 1(the default version of hbase 1.1.2):

1. in the beginning, client-2 starts to sends requests and clie= nt-1 not. the throughput of client-2 keep stable

2. whe= n client-1 starts, the throughputs of both client-1 and client-2 are very u= nstable, that is to say client-1 influence client-2 seriously

3. the average hbase throughput is 36641 .

3D"=E5=86=85=E5=B5=8C=E5=9B=BE=E7=89=87

Afterwords, we assign 150 handlers to = table-2 and 3 handlers to table-1 with mutilple-type queue feature. as show= n in future 2, the throughputs of both client-1 and client-2 are more smoot= h, the average hbase throughput is 51653 , 41% higher.

so we think=C2=A0in some cases=C2=A0the feature is a improvement for running multiple workloads on = a single hbase cluster, =C2=A0let me know if anything is incorrect o= r inaccurate .

Thanks a lot for your help!

=

2017-04-11 = 13:58 GMT+08:00 =E8=8C=83=E8=8C=83=E6=AC=A3=E6=AC=A3 <= libisthanks@gmai= l.com>:

Now, the feature HBASE-11355 seperates the single Call Queue = into MutilQueue(get call queue, write call queue and scan call queue), and = each type queue can specify fixed number of handlers. It's helpful in s= ome outages , to avoid all read or all write requests ran out of handler th= reads.=C2=A0

however, there are still several problems :

1. workloads in the same request type(get/write/scan) may inf= luence each other as before, consider the following scenario:

(1) both client-1 and client-2 send write requests, the clien= t-1 write the large objects(100KB record) , and client-2 write the small ob= jects (1KB record). the client -1 will ran out of all handler threads of th= e write-queue, and decrease the client-2 throughput

(2) both client-3 and client-4 send get requests, the client-= 3 search all data from lots of hfiles( all search key are equally popular),= read latency is high. the client-4 do not require any I/O resources(say, d= ata is cached). the client-3 will ran out of all handler threads of the get= -queue, and increase the read latency of client-4

2. administor can't increate/decrease the handler number = for the specified queue easily


we are trying to implement a new Mutilple-Typed Queue, admini= stor can create a queue with a specified number of handler for specified ta= ble and specified request type(get/write/scan), as:

create_queue 'queue1' ,{= 'handler' =3D> 100}

grant_queue 'table1','scan','queue1'<= /span>

grant_queue 'tableN','scan','queue1'<= /span>


create_queue 'queue2' ,{'handler' =3D> 50}=

grant_queue 'table2','write','queue2'=


the idea based on the fact that the workload for a specified = table and request type will be unique.=C2=A0

in addition, administor can mana= ger the queue with commands:

//easily increase/decrease handlers

alter_queue 'queue1' ,{'handler' =3D> 50}<= /span>

//list all queues

list_queues

//drop the specified queue

drop_queue 'queue1'


I am wondering if the developers could look at the idea and l= et me know if anything is incorrect or inaccurate, or if I have missed anyt= hing.=C2=A0


Thanks a lot for your help!


--001a113fb63230ba02054d45f24e-- --001a113fb63230ba05054d45f24f--