Return-Path: X-Original-To: apmail-hbase-user-archive@www.apache.org Delivered-To: apmail-hbase-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 831159188 for ; Wed, 11 Jul 2012 15:26:35 +0000 (UTC) Received: (qmail 77425 invoked by uid 500); 11 Jul 2012 15:26:33 -0000 Delivered-To: apmail-hbase-user-archive@hbase.apache.org Received: (qmail 77161 invoked by uid 500); 11 Jul 2012 15:26:33 -0000 Mailing-List: contact user-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@hbase.apache.org Delivered-To: mailing list user@hbase.apache.org Received: (qmail 77136 invoked by uid 99); 11 Jul 2012 15:26:32 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 Jul 2012 15:26:32 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=FSL_RCVD_USER,RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [74.125.82.169] (HELO mail-we0-f169.google.com) (74.125.82.169) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 Jul 2012 15:26:23 +0000 Received: by werl57 with SMTP id l57so1104485wer.14 for ; Wed, 11 Jul 2012 08:26:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=JD/nePwVEig3tsEW+AIJczJVzbieLBBZtZnUnL7K+GE=; b=en7h10y8ol34DmC7DEGq9CJcXQYrl+kP4lzlmycTjJ6KwaSpDjU2VaA/Q+5cb0hjY/ lEAJyLAkcHI95xFVwChB08LkqxlY4cRLDfsta6a1vtcJXsm8nCNTrB9A1aPy9S6rsLsD Q/cxWNk1nBToTEuCdTO8vyO+Dh1zrbG8e3sRfzhBlUw9DdwjdQrexwwnl0GUuWQ45vBC 337R4Dva4xr7czoYzDPrQ8D1SRQZzRzmsbHHZnWEe+XvTFbSeGX6p7RiX67o14giyC2e jmoKJOlwfdnc/gaT4mPgbzrpD5UodmOvIFOWI7TWvt/JuAx5LcFYl5gFFBVHQe9+JD+a JqKw== MIME-Version: 1.0 Received: by 10.216.218.95 with SMTP id j73mr19103331wep.193.1342020363135; Wed, 11 Jul 2012 08:26:03 -0700 (PDT) Received: by 10.216.162.74 with HTTP; Wed, 11 Jul 2012 08:26:03 -0700 (PDT) X-Originating-IP: [209.117.251.114] Date: Wed, 11 Jul 2012 10:26:03 -0500 Message-ID: Subject: CellCounter -- Exceeded limits on number of counters From: Patrick Schless To: user@hbase.apache.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkGDtfMy9BcoZ7DXjAmDIPb0R7hDgXmihHdh9trd+FxtbrJPwouZv+sLinuHWrGMsizaB/K I am trying to find out the number of data points (cells) in a table with "hbase org.apache.hadoop.hbase.mapreduce.CellCounter ". on a very small table (3 cells), it works fine. On a table with a couple thousand cells, I get this error (4 times): org.apache.hadoop.mapred.Counters$CountersExceededException: Error: Exceeded limits on number of counters - Counters=120 Limit=120 at org.apache.hadoop.mapred.Counters$Group.getCounterForName(Counters.java:316) at org.apache.hadoop.mapred.Counters.findCounter(Counters.java:450) at org.apache.hadoop.mapred.Task$TaskReporter.getCounter(Task.java:590) at org.apache.hadoop.mapred.Task$TaskReporter.getCounter(Task.java:537) at org.apache.hadoop.mapreduce.TaskInputOutputContext.getCounter(TaskInputOutputContext.java:88) at org.apache.hadoop.hbase.mapreduce.CellCounter$CellCounterMapper.map(CellCounter.java:134) at org.apache.hadoop.hbase.mapreduce.CellCounter$CellCounterMapper.map(CellCounter.java:77) at org.apache.hadoop.mapreduce.Mapper.run(Mapper.java:144) at org.apache.hadoop.mapred.MapTask.runNewMapper(MapTask.java:647) at org.apache.hadoop.mapred.MapTask.run(MapTask.java:323) at org.apache.hadoop.mapred.LocalJobRunner$Job.run(LocalJobRunner.java:210) I've been googling, but all I can find is stuff along the lines of "I know this is bad, but how do I increase the counter limit?" For a table with only a few thousand cells, I think I must be doing something wrong if I'm hitting a limit of a built-in mapreduce job (I'd expect it to run slower, rather than fail). I'm running hbase 0.90.6 on a small test cluster (1 NN, 1 SNN, 1JT, 1 HMaster, 2 ZK, 3 slaves). Is increasing the counter limit the right strategy here, or is there some way to use CellCounter without changing that? In the "real" cluster, there will be more slaves, but also quite a bit more data.