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 F2E191953B for ; Wed, 13 Apr 2016 07:54:35 +0000 (UTC) Received: (qmail 33841 invoked by uid 500); 13 Apr 2016 07:54:29 -0000 Delivered-To: apmail-lucene-solr-user-archive@lucene.apache.org Received: (qmail 33769 invoked by uid 500); 13 Apr 2016 07:54:29 -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 33754 invoked by uid 99); 13 Apr 2016 07:54:28 -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; Wed, 13 Apr 2016 07:54:28 +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 44536C0C72 for ; Wed, 13 Apr 2016 07:54:28 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.806 X-Spam-Level: * X-Spam-Status: No, score=1.806 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L3=1.899, RP_MATCHES_RCVD=-0.001, 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 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 P61267oLfw_7 for ; Wed, 13 Apr 2016 07:54:26 +0000 (UTC) Received: from frodo.elyograg.org (frodo.elyograg.org [166.70.79.219]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTP id 9FDCF5F24D for ; Wed, 13 Apr 2016 07:54:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by frodo.elyograg.org (Postfix) with ESMTP id E940954CD for ; Wed, 13 Apr 2016 01:54:23 -0600 (MDT) 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= 1460534063; bh=5L1zFO7v0RcjD5py2KFtDBZXZUbeNIdNjnnlAWePA2Y=; b=o kGoyZaFxA2kkgz81x/ItkXZZ+fTQ18HQgxtbCk1uxpsrTtYi6pSgllpIEflfWsjc LNImBV/QG47eUpR7F4ERYMqZ84gfIfhgKaH/acfWwlGZTTVDVLzCQCT1YHJxpE+1 NmQIYRVgJUbkqcPaMRkrqEZ9NwFUwaOtIegzqUhLbg= 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 JfkKw50yKIiD for ; Wed, 13 Apr 2016 01:54:23 -0600 (MDT) 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 48FDF54C6 for ; Wed, 13 Apr 2016 01:54:23 -0600 (MDT) Subject: Re: Cache problem To: solr-user@lucene.apache.org References: <56FD255D.8070803@mdpi.com> <570BA902.9040201@mdpi.com> <570CC14C.4040906@mdpi.com> <570D9716.6040504@elyograg.org> <570DEDCC.6030106@mdpi.com> From: Shawn Heisey Message-ID: <570DFB2E.8080408@elyograg.org> Date: Wed, 13 Apr 2016 01:54:22 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <570DEDCC.6030106@mdpi.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 4/13/2016 12:57 AM, Bastien Latard - MDPI AG wrote: > Thank you Shawn & Reth! > > So I have now some questions, again > > > Remind: I have only Solr running on this server (i.e.: java + tomcat). > > /BTW: I needed to increase previously the java heap size because I > went out of memory. Actually, you only see here 2Gb (8Gb previously) > for JVM because I automatically restart tomcat for a better > performance every 30 minutes if no DIH running./ If you size your heap appropriately and properly tune garbage collection, restarting like this should be unnecessary. > Question #1: > From the picture above, we see Physical memory: ~60Gb > * -> is this because of -Xmx40960m AND -XX:MaxPermSize=20480m ? * I don't actually know whether permgen is allocated from the heap, or *in addition* to the heap. Your current allocated heap size is 20GB, which means that at most Java is taking up 30GB, but it might be just 20GB. The other 30-40GB is used by the operating system -- for disk caching (the page cache). It's perfectly normal for physical memory to be almost completely maxed out. The physical memory graph is nearly useless for troubleshooting. Here's a screenshot of one of my servers: https://www.dropbox.com/s/55d4x33tpyyaoff/solr-dashboard-physical-mem.png?dl=0 Notice that the max heap here is 8GB ... yet physical memory has 59GB allocated -- 95 percent. There are some additional java processes taking up a few GB, but the vast majority of the memory is used by the OS page cache. > Question #2: > /"The OS caches the actual index files"./ > > *Does this mean that OS will try to cache 47.48Gb for this index? (if > not, how can I know the size of the cache) > */Or are you speaking about page cache > ?/ I am talking about the page cache, also known as the disk cache. The OS will potentially use *all* unassigned memory for the page cache. You can ask your operating system how much memory is being used for this purpose. > Question #3: > /"documentCache does live in Java heap" > /*Is there a way to know the real size used/needed by this caching?* Solr does not report memory usage with that much detail. Perhaps one day it will, but we're not there yet. The size of an entry in the documentCache should be approximately the size of the stored data for that document, plus Java overhead required to hold the data. The filterCache is the one that usually uses a large amount of memory. Thanks, Shawn