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 3CB7917C49 for ; Tue, 6 Oct 2015 11:25:08 +0000 (UTC) Received: (qmail 17774 invoked by uid 500); 6 Oct 2015 10:55:44 -0000 Delivered-To: apmail-lucene-solr-user-archive@lucene.apache.org Received: (qmail 17704 invoked by uid 500); 6 Oct 2015 10:55:44 -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 17693 invoked by uid 99); 6 Oct 2015 10:55:44 -0000 Received: from Unknown (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 06 Oct 2015 10:55:44 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id D612B180A4F for ; Tue, 6 Oct 2015 10:55:43 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 0.991 X-Spam-Level: X-Spam-Status: No, score=0.991 tagged_above=-999 required=6.31 tests=[KAM_LAZY_DOMAIN_SECURITY=1, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=disabled Received: from mx1-eu-west.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id OZdWMREENNii for ; Tue, 6 Oct 2015 10:55:37 +0000 (UTC) Received: from sbexch04.sb.statsbiblioteket.dk (sbexch04.sb.statsbiblioteket.dk [130.225.24.70]) by mx1-eu-west.apache.org (ASF Mail Server at mx1-eu-west.apache.org) with ESMTPS id 6E11027DC7 for ; Tue, 6 Oct 2015 10:55:36 +0000 (UTC) Received: from sbexch04.sb.statsbiblioteket.dk (130.225.24.70) by sbexch04.sb.statsbiblioteket.dk (130.225.24.70) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 6 Oct 2015 12:55:29 +0200 Received: from [130.225.25.26] (130.225.25.26) by sbexch04.sb.statsbiblioteket.dk (130.225.24.70) with Microsoft SMTP Server id 15.0.1076.9 via Frontend Transport; Tue, 6 Oct 2015 12:55:29 +0200 Message-ID: <1444128921.2669.144.camel@te-prime> Subject: Re: Pressed optimize and now SOLR is not indexing while optimize is going on From: Toke Eskildsen Reply-To: To: Date: Tue, 6 Oct 2015 12:55:21 +0200 In-Reply-To: References: Organization: State and University Library, Denmark Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu2 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit On Mon, 2015-10-05 at 17:26 -0400, Siddhartha Singh Sandhu wrote: > Following up on that: Would having an SSD make considerable difference in > speed? Yes, but only to a point. The UK Web Archive has done some tests on optimizing indexes on both spinning drives and SSDs: https://github.com/ukwa/shine/tree/master/python/test-logs With spinning drives, their machines maxed out on IOWait. With SSD, the machine maxed out on CPU. That might sound great, but the problem is that optimizing on a single shard is single threaded (at least for Solr 4.10.x), so if there is only a single shard on the machine, only 1 CPU is running at full tilt. There is always a bottleneck. What might help is that the SSD (probably) does not get bogged down by the process, so it should be much better at handling other requests while the optimization is running. - Toke Eskildsen, State and University Library, Denmark