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 5F39B173B6 for ; Fri, 15 May 2015 13:08:10 +0000 (UTC) Received: (qmail 37229 invoked by uid 500); 15 May 2015 13:08:05 -0000 Delivered-To: apmail-hadoop-mapreduce-user-archive@hadoop.apache.org Received: (qmail 37123 invoked by uid 500); 15 May 2015 13:08:05 -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 37113 invoked by uid 99); 15 May 2015 13:08:05 -0000 Received: from Unknown (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 15 May 2015 13:08:05 +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 8E3D2C137E for ; Fri, 15 May 2015 13:08:04 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -0.121 X-Spam-Level: X-Spam-Status: No, score=-0.121 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (1024-bit key) header.d=yandex.ru Received: from mx1-eu-west.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id WIPLqJIdrwDF for ; Fri, 15 May 2015 13:08:03 +0000 (UTC) Received: from forward17.mail.yandex.net (forward17.mail.yandex.net [95.108.253.142]) by mx1-eu-west.apache.org (ASF Mail Server at mx1-eu-west.apache.org) with ESMTPS id B2CBA21784 for ; Fri, 15 May 2015 13:08:02 +0000 (UTC) Received: from web23g.yandex.ru (web23g.yandex.ru [IPv6:2a02:6b8:0:1402::33]) by forward17.mail.yandex.net (Yandex) with ESMTP id DC3B3106155D for ; Fri, 15 May 2015 16:07:54 +0300 (MSK) Received: from 127.0.0.1 (localhost [127.0.0.1]) by web23g.yandex.ru (Yandex) with ESMTP id 9ECB33201620 for ; Fri, 15 May 2015 16:07:54 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1431695274; bh=8f/7J9dYdTSvRk70PKcDqx8gvhhs2icaybEvUsuv+u4=; h=From:To:Subject:Date; b=UQ8uSlSumUzvIWmzy2sTNA0AGiqxuTuIVneYZXtGwKCgKSu4YHONmzhO4eTI9TcFH 2r2ZNaMHI1IzniX9h849s9KzC7289R16NFIMTfVmuTTsIB6pF0KmMjw9lvj5vKij6L RD6H9qDOXXHeS3L46YPmOOCpTmF+0TIztAPHyINo= Received: by web23g.yandex.ru with HTTP; Fri, 15 May 2015 16:07:54 +0300 From: g10ck To: user@hadoop.apache.org Subject: Impala returns error: "Bad status for request 5241: TGetOperationStatusResp" MIME-Version: 1.0 Message-Id: <3749651431695274@web23g.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Fri, 15 May 2015 16:07:54 +0300 Content-Transfer-Encoding: 7bit Content-Type: text/plain Hello, I'm running CDH 5.2.1. When I tried to execute impala query on huge tables via HUE UI I got such error: Bad status for request 5241: TGetOperationStatusResp(status=TStatus(errorCode=None, errorMessage=None, sqlState=None, infoMessages=None, statusCode=0), operationState=5, errorMessage=None, sqlState=None, errorCode=None) First, I've tried to execute the same query via impala-shell on one of my worker-nodes. I was confused that error message was: Query did not have enough memory to get the minimum required buffers. Backend 3:Memory Limit Exceeded I've checked impalad startup options. Command that gives me `ps aux | grep impalad` is: /opt/cloudera/parcels/CDH-5.2.1-1.cdh5.2.1.p0.12/lib/impala/sbin-retail/impalad --flagfile=/var/run/cloudera-scm-agent/process/7492-impala-IMPALAD/impala-conf/impalad_flags And there is the content of the above flag_file: -beeswax_port=21000 -fe_port=21000 -be_port=22000 -llama_callback_port=28000 -hs2_port=21050 -enable_webserver=true -mem_limit=128849018880 !!! -webserver_port=25000 -max_result_cache_size=100000 -state_store_subscriber_port=23000 -statestore_subscriber_timeout_seconds=30 -scratch_dirs=/disk1/impala/impalad,/disk10/impala/impalad,/disk2/impala/impalad,/disk3/impala/impalad,/disk4/impala/impalad,/disk5/impala/impalad,/disk6/impala/impalad,/disk7/impala/impalad,/disk8/impala/impalad,/disk9/impala/impalad,/opt/impala/impalad,/disk11/impala/impalad,/disk12/impala/impalad -default_query_options !!! -log_filename=impalad -hostname=my_hostname -state_store_host=my_host -local_nodemanager_url=my_host:8042 -llama_host=my_host -llama_port=15000 -enable_rm=true -pool_conf_file=pool-acls.txt -cgroup_hierarchy_path=/var/run/cloudera-scm-agent/cgroups/cpu/hadoop-yarn -state_store_port=24000 -catalog_service_host=my_host -catalog_service_port=26000 -local_library_dir=/var/lib/impala/udfs -llama_max_request_attempts=5 -llama_registration_timeout_secs=30 -llama_registration_wait_secs=3 -fair_scheduler_allocation_path=/var/run/cloudera-scm-agent/process/7494-impala-IMPALAD/impala-conf/fair-scheduler.xml -llama_site_path=/var/run/cloudera-scm-agent/process/7494-impala-IMPALAD/impala-conf/llama-site.xml -disk_spill_encryption=false So, I've tried to change -default_query_options to: -default_query_options=mem_limit=128849018880 Now, if I do 'set;' in HUE or impala-shell I see: MEM_LIMIT: [128849018880] Before there was value "0". My queries were succesfully executed. Can you explain, why I have to set mem_limit under parameter "-default_query_options"? I thought that default memory limit for impalad is set by "mem_limit" option