Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bKrJv-0007zT-TM for pgsql-performance@arkaria.postgresql.org; Wed, 06 Jul 2016 18:13:12 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bKrJv-0002EX-Gl for pgsql-performance@arkaria.postgresql.org; Wed, 06 Jul 2016 18:13:11 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bKrJu-0002E0-JM for pgsql-performance@postgresql.org; Wed, 06 Jul 2016 18:13:10 +0000 Received: from mail-vk0-x233.google.com ([2607:f8b0:400c:c05::233]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1bKrJr-0002kV-9g for pgsql-performance@postgresql.org; Wed, 06 Jul 2016 18:13:10 +0000 Received: by mail-vk0-x233.google.com with SMTP id v6so44874086vkb.2 for ; Wed, 06 Jul 2016 11:13:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AbkkpsAcyhA49xzWOGt/Q9VQF/PRGtsyqrb4uAFEhgY=; b=wcOjskKGn25soRE75fJh9S1wjXXzAIeKVl1fZfurHzQeffFyBPhFps3xCfG4NO4QNo 2tu1tLj1f2qYB90r4o37OMhFTeg0LC2kiI7sSc6PSBofAlt7EMG8pzseSn/YbmKCydHE +VMmKed5GRjA9mEn4WWw+LIKKOivit2Fq7H9EqX8Z0m460qcoifXj5ZYVWZLhSufo0F9 UsdrvjlhTSf4B/17doovOtdOdrvnvnTo6jh6VdfWuXqCqAqXDdaDhNq3bVf3/muODDbT TCpud232Rz683cFq2aZXuzfEhb2OatPQu6cq1Z+Lg8ywlvAnqekQ1BQEW2m09DNUjVny 9imA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AbkkpsAcyhA49xzWOGt/Q9VQF/PRGtsyqrb4uAFEhgY=; b=O1+ZAVdrYuxgdmsFijb40lkeusPM0wPzjKMF9377PnCKj/k7uhRdkm1ocvMSubuCLI vxHMAZq+aMxnfHreTfoUO8IqL7u8472CuX+rZ9E+UiMeMewV8J3anwkzAWXQ3B6d7JYk gbGQZZPWNK/4hRITbURIlMxKMioue/IZBaztOmtxh+/a4sZ5ZPr/plef9dyuBX/9fPly VCUHlUE00mJ9/jsFRBpZv/RzuLvky67e4X8r/vAJiiLNUMzrTT7X2U5JsCAnxKEetZGI aELOF/a/3fxWTaYgQgBke9bYeDy6bdEG+8fnwUkY11w+hrae2tZ9BhJfpm7e5Nq4TsKr SfUQ== X-Gm-Message-State: ALyK8tLwfJTQJqL4GVSI8kJyvG5e+UV6uoFvWj5WhuEPXfCgserbIW0zLrzns6o36tYMdjNgW5LlblJ/nsGMcw== X-Received: by 10.31.96.70 with SMTP id u67mr10885920vkb.107.1467828785480; Wed, 06 Jul 2016 11:13:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.53.8 with HTTP; Wed, 6 Jul 2016 11:13:05 -0700 (PDT) In-Reply-To: References: From: Merlin Moncure Date: Wed, 6 Jul 2016 13:13:05 -0500 Message-ID: Subject: Re: Tuning guidelines for server with 256GB of RAM and SSDs? To: Kaixi Luo Cc: postgres performance list Content-Type: text/plain; charset=UTF-8 X-Pg-Spam-Score: -2.7 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org On Tue, Jul 5, 2016 at 9:50 AM, Kaixi Luo wrote: > Hello, > > I've been reading Mr. Greg Smith's "Postgres 9.0 - High Performance" book > and I have some questions regarding the guidelines I found in the book, > because I suspect some of them can't be followed blindly to the letter on a > server with lots of RAM and SSDs. > > Here are my server specs: > > Intel Xeon E5-1650 v3 Hexa-Core Haswell > 256GB DDR4 ECC RAM > Battery backed hardware RAID with 512MB of WriteBack cache (LSI MegaRAID SAS > 9260-4i) > RAID1 - 2x480GB Samsung SSD with power loss protection (will be used to > store the PostgreSQL database) > RAID1 - 2x240GB Crucial SSD with power loss protection. (will be used to > store PostgreSQL transactions logs) > > First of all, the book suggests that I should enable the WriteBack cache of > the HWRAID and disable the disk cache to increase performance and ensure > data safety. Is it still advisable to do this on SSDs, specifically the step > of disabling the disk cache? Wouldn't that increase the wear rate of the > SSD? At the time that book was written, the majority of SSDs were known not to be completely honest and/or reliable about data integrity in the face of a power event. Now it's a hit or miss situation (for example, see here: http://blog.nordeus.com/dev-ops/power-failure-testing-with-ssds.htm). The intel drives S3500/S3700 and their descendants are the standard against which other drives should be judged IMO. The S3500 family in particular offers tremendous value for database usage. Do your research; the warning is still relevant but the blanket statement no longer applies. Spinning drives are completely obsolete for database applications in my experience. Disabling write back cache for write heavy database loads will will destroy it in short order due to write amplication and will generally cause it to underperform hard drives in my experience. With good SSDs and a good motherboard, I do not recommend a caching raid controller; software raid is a better choice for many reasons. One parameter that needs to be analyzed with SSD is effective_io_concurrency. see https://www.postgresql.org/message-id/CAHyXU0yiVvfQAnR9cyH%3DHWh1WbLRsioe%3DmzRJTHwtr%3D2azsTdQ%40mail.gmail.com merlin -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance