Return-Path: Delivered-To: apmail-lucene-solr-user-archive@minotaur.apache.org Received: (qmail 21478 invoked from network); 2 Sep 2010 08:55:31 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 2 Sep 2010 08:55:31 -0000 Received: (qmail 16912 invoked by uid 500); 2 Sep 2010 08:55:29 -0000 Delivered-To: apmail-lucene-solr-user-archive@lucene.apache.org Received: (qmail 16353 invoked by uid 500); 2 Sep 2010 08:55:25 -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 16340 invoked by uid 99); 2 Sep 2010 08:55:24 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 Sep 2010 08:55:24 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [130.225.24.68] (HELO sbexch03.sb.statsbiblioteket.dk) (130.225.24.68) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 Sep 2010 08:55:19 +0000 Received: from [172.18.226.237] (172.18.226.237) by sbexch03.sb.statsbiblioteket.dk (130.225.24.68) with Microsoft SMTP Server id 8.1.436.0; Thu, 2 Sep 2010 10:54:57 +0200 Subject: Re: Hardware Specs Question From: Toke Eskildsen Reply-To: te@statsbiblioteket.dk To: "solr-user@lucene.apache.org" In-Reply-To: References: <1957FC4418E54F29BF7545C64017F545@udc70634P002> <79B4EBC0817944EBAC0ECA72B45F14D9@udc70634P002> Content-Type: text/plain; charset="UTF-8" Organization: State and University Library, Denmark Date: Thu, 2 Sep 2010 10:54:51 +0200 Message-ID: <1283417692.7260.56.camel@te-prime> MIME-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit On Thu, 2010-09-02 at 03:37 +0200, Lance Norskog wrote: > I don't know how much SSD disks cost, but they will certainly cure the > disk i/o problem. We've done a fair amount of experimentation in this area (1997-era SSDs vs. two 15.000 RPM harddisks in RAID 1 vs. two 10.000 RPM harddisks in RAID 0). The harddisk setups never stood a chance for searching. With current SSD's being faster than harddisks for writes too, they'll also be better for index building, although not as impressive as for searches. Old notes at http://wiki.statsbiblioteket.dk/summa/Hardware With consumer level SSD's, there is more bang-for-the-buck than RAIDing up with high-end harddisks. They should be the first choice when IO is an issue. There are of course opposing views on this issue. Some people think enterprise: Expensive and very reliable systems where consumer hardware is a big no-no. The price point for pro SSDs might make them unfeasible in such a setup. Other go for cheaper setups and handle the reliability issues with redundancy. I'm firmly in the second camp, but it is obviously not an option for all people. A point of concern is writes. Current consumer SSDs uses wear leveling and they can take a lot of punishment (as a rough measurement: The amount of free space times 10.000). They might not be suitable for holding massive databases with thousands of writes/second, but they can surely handle the measly amount of writes required for Lucene index updating and searching. A long story short: Put a quality consumer SSD in each server and be happy.