Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id 9B019B5DBC0 for ; Fri, 17 Jun 2011 06:13:42 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 92223-02 for ; Fri, 17 Jun 2011 09:13:36 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-wy0-f174.google.com (mail-wy0-f174.google.com [74.125.82.174]) by mail.postgresql.org (Postfix) with ESMTP id 2BF3BB5D801 for ; Fri, 17 Jun 2011 06:13:35 -0300 (ADT) Received: by wyb38 with SMTP id 38so165320wyb.19 for ; Fri, 17 Jun 2011 02:13:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=/QIfUOfIjfOHKo09ov/IJvGTGwO2pZMsy+NoVnDODG4=; b=lYtj04aqiqy2LubQS5QOiL4mW8PBKGar4+mmu7mopx3L3XqKm6Acm7HAjWqjyw1P+G Cu+yXn5Kp6j7A1GwDvEPt+82J1gx9q6z9CVa5uJufvC3fZ4pannb/pye9SbgjUV4+z0o +p+4sy96rlPwHobEWcMqrVqU8qvRBXFYpd6WA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=GcD7DakAQ9406Rya2O7bKuDHZWb4cu9CRRlqIiAIHnrEjyMauQ4kpJrpW1PEQcnfUI fCTJ/EKwC4xsFklwMZRQNtojjuK65NuIHM2fCsTkoYf2a+x244chNZFSMFscmFjIMh0t ly32nSEPPuoH6ArEzh2Kt9H5mVXkF4794qz18= Received: by 10.227.198.130 with SMTP id eo2mr1882412wbb.50.1308302015367; Fri, 17 Jun 2011 02:13:35 -0700 (PDT) Received: from [192.168.1.36] ([194.153.94.2]) by mx.google.com with ESMTPS id o19sm784438wbh.55.2011.06.17.02.13.34 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 17 Jun 2011 02:13:34 -0700 (PDT) Subject: Re: Performance advice for a new low(er)-power server Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Haestan In-Reply-To: <4DFA4EB7.1020701@2ndQuadrant.com> Date: Fri, 17 Jun 2011 11:13:32 +0200 Cc: pgsql-performance@postgresql.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DFA4EB7.1020701@2ndQuadrant.com> To: Greg Smith X-Mailer: Apple Mail (2.1084) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.898 tagged_above=-10 required=5 tests=BAYES_00=-1.9, FREEMAIL_FROM=0.001, RFC_ABUSE_POST=0.001 X-Spam-Level: X-Archive-Number: 201106/151 X-Sequence-Number: 44084 On Jun 16, 2011, at 20:43, Greg Smith wrote: > The layout you proposed (OS+WAL , data) might be effective, but if = your write volume is low it may not be much of an improvement at all = over a simple RAID1 of two drives. The odds that you are going to = correctly lay out individual sections of a disk array with only two = pairs to spread the data across aren't good. If this is all you have to = work with, a 4-disk RAID10 would at least guarantee you're taking = advantage of all four drives. With that controller, it should be almost = twice as fast in all cases as hooking up only two drives. The data is more or less constantly rewritten (it contains hourly = updated travel related data). Therefore, I really tend to buy 4 disks = from the start on. > There is another possibility I would suggest you consider. You could = buy the server with a single pair of drives now, then wait to see what = performance is like before filling the other two slots. It is far = easier to figure out what drive technology makes sense if you have = measurements from an existing system to guide that decision. And you = may be able to get newer drives from your vendor that slide into the = empty slots. You may not ever even need more than a single RAID-1 pair. = I see lots of people waste money on drives that would be better spent = on RAM. Actually, there are already two older servers in place right now. The = data is about 14GB in size and slowly rising. Considering the price for = RAM I can easily afford to install more RAM than the db data is in size. = I was aiming for 24GB. But even then, I cannot be sure that no queries = will read from the disk. AFAIK, there is no way to force all the data to = stay in cache (shared_buffers for example).=20 Thank you for your input so far. Regards, Tom.=