Return-Path: X-Original-To: apmail-lucene-solr-user-archive@minotaur.apache.org Delivered-To: apmail-lucene-solr-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 CBC4A19D11 for ; Tue, 8 Mar 2016 02:45:30 +0000 (UTC) Received: (qmail 31043 invoked by uid 500); 8 Mar 2016 02:45:26 -0000 Delivered-To: apmail-lucene-solr-user-archive@lucene.apache.org Received: (qmail 30810 invoked by uid 500); 8 Mar 2016 02:45:26 -0000 Mailing-List: contact solr-user-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: solr-user@lucene.apache.org Delivered-To: mailing list solr-user@lucene.apache.org Received: (qmail 30798 invoked by uid 99); 8 Mar 2016 02:45:26 -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; Tue, 08 Mar 2016 02:45:26 +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 81970C0D5B for ; Tue, 8 Mar 2016 02:45:25 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -0.431 X-Spam-Level: X-Spam-Status: No, score=-0.431 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.329, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (1024-bit key) header.d=elyograg.org Received: from mx2-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 UVKnn4hg2hq0 for ; Tue, 8 Mar 2016 02:45:24 +0000 (UTC) Received: from frodo.elyograg.org (frodo.elyograg.org [166.70.79.219]) by mx2-lw-us.apache.org (ASF Mail Server at mx2-lw-us.apache.org) with ESMTP id E7D115FAE8 for ; Tue, 8 Mar 2016 02:45:23 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by frodo.elyograg.org (Postfix) with ESMTP id 534826EC for ; Mon, 7 Mar 2016 19:45:16 -0700 (MST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=elyograg.org; h= content-transfer-encoding:content-type:content-type:in-reply-to :mime-version:user-agent:date:date:message-id:from:from :references:subject:subject:received:received; s=mail; t= 1457405116; bh=7LQCb139UeC/cxb5LXqWyU/s3nGmsRfsK2jm+AAZo8Q=; b=m wFeROUxWExUu3TO/+OW9R2xe29bqUSDG/+3JQdcIZAczsi3NzhgQt996ANUf+Ka1 Wx+fqVaCVv8vAob/8xo/0nS6rqGz0SfYa7o/8sCJCsM4S3PPvyEs8xT4E9wOSkrS 8OduJemEeX8XhOVagp5sWSxog7u66xF7NkdQ7ZDleM= X-Virus-Scanned: Debian amavisd-new at frodo.elyograg.org Received: from frodo.elyograg.org ([127.0.0.1]) by localhost (frodo.elyograg.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id XteM7JYZLR9C for ; Mon, 7 Mar 2016 19:45:16 -0700 (MST) Received: from [192.168.1.107] (107.int.elyograg.org [192.168.1.107]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: elyograg@elyograg.org) by frodo.elyograg.org (Postfix) with ESMTPSA id 000D131D for ; Mon, 7 Mar 2016 19:45:15 -0700 (MST) Subject: Re: High Cpu sys usage To: solr-user@lucene.apache.org References: <56DC4C1B.802@elyograg.org> <1457342634.4503.42.camel@tokemon> From: Shawn Heisey Message-ID: <56DE3CCB.1030708@elyograg.org> Date: Mon, 7 Mar 2016 19:45:31 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <1457342634.4503.42.camel@tokemon> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 3/7/2016 2:23 AM, Toke Eskildsen wrote: > How does this relate to YouPeng reporting that the CPU usage increases? > > This is not a snark. YouPeng mentions kernel issues. It might very well > be that IO is the real problem, but that it manifests in a non-intuitive > way. Before memory-mapping it was easy: Just look at IO-Wait. Now I am > not so sure. Can high kernel load (Sy% in *nix top) indicate that the IO > system is struggling, even if IO-Wait is low? It might turn out to be not directly related to memory, you're right about that. A very high query rate or particularly CPU-heavy queries or analysis could cause high CPU usage even when memory is plentiful, but in that situation I would expect high user percentage, not kernel. I'm not completely sure what might cause high kernel usage if iowait is low, but no specific information was given about iowait. I've seen iowait percentages of 10% or less with problems clearly caused by iowait. With the available information (especially seeing 700GB of index data), I believe that the "not enough memory" scenario is more likely than anything else. If the OP replies and says they have plenty of memory, then we can move on to the less common (IMHO) reasons for high CPU with a large index. If the OS is one that reports load average, I am curious what the 5 minute average is, and how many real (non-HT) CPU cores there are. Thanks, Shawn