Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bLCgq-0007Y2-Qu for pgsql-performance@arkaria.postgresql.org; Thu, 07 Jul 2016 17:02:16 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bLCgq-00018X-EB for pgsql-performance@arkaria.postgresql.org; Thu, 07 Jul 2016 17:02:16 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bLCfA-00075b-4Y for pgsql-performance@postgresql.org; Thu, 07 Jul 2016 17:00:32 +0000 Received: from mail-vk0-x22b.google.com ([2607:f8b0:400c:c05::22b]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1bLCf2-0006hh-Hh for pgsql-performance@postgresql.org; Thu, 07 Jul 2016 17:00:31 +0000 Received: by mail-vk0-x22b.google.com with SMTP id f7so12833573vkb.3 for ; Thu, 07 Jul 2016 10:00:24 -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=CJcF9uc2VnKtKzDuqISXPPpOkSV+tFqyI3GleZdPToI=; b=TCMxrr1Xg2sJ8+OxX7CMuMwXp84j+Cs5wUAGZcDOE9Mw0Jsnrv/Qzq9bmzFHdzk0Yt 8/Kp+5yvy6Zi2zB66yEVLWac98rDsBVzeaN0XAWRz1iDPK7jZqNOK/JyLYKduZrVIHTu YxEKa28nnS0kRPKQQulWyJTZF8kM/F0HCICZFmRQTup78jQtHzHoWTL48aerwMNvW6XP 4SlrhyhllQMYtegpoSPTs3iem56kAqcadh27/7RWiBI2t7UVS5gXBgLO3tBlB81cOKsY B97GqGVtoS5gUoCSD9EJJ1LqEVCSjnoUWbFi+GGMwWdokr//D/k6x3dkB0nN68yNIiOt 5gjA== 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=CJcF9uc2VnKtKzDuqISXPPpOkSV+tFqyI3GleZdPToI=; b=iUC4UdjPnivJhq6o2BgiF7q20g5HWPmHTKtzr7ZRIyzw20a1OXpYbBxYGbX2erRfzn ji8kfuNz77/WK1E/UUGMN+7vL7p+kkXW2DSlWg83qfiIlticmQn0Ti7ohToaDZzY3sL2 uh0rt0ins5y2zAwU2TDMFmK4JaVhoiNbVTvgGT1h/CtOdDnq2mJF+kJwvbGkqd6KBRwI HBCEEexIhE4iPx75I6VVKNJ3EYdXlAmY3NDEozF6HcFRNmUXf+wXgxDYspGtmR2XKL0P p/R3mIZq6xgmcHuN4C64s0ECWrMNvPUnsJT6W5SovCdDAYRFyLf1IzknrijEa6oJwy9k TlYQ== X-Gm-Message-State: ALyK8tK0Au1o6lwYDbmWtcgoicIf/g2jGzupawwFpniZ0syt0qGj2Vf2YWBFqqFqSwav1NMK072EKrra8arKgw== X-Received: by 10.159.32.227 with SMTP id 90mr569161uaa.85.1467910823443; Thu, 07 Jul 2016 10:00:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.147.219 with HTTP; Thu, 7 Jul 2016 10:00:22 -0700 (PDT) In-Reply-To: References: From: Scott Marlowe Date: Thu, 7 Jul 2016 11:00:22 -0600 Message-ID: Subject: Re: Tuning guidelines for server with 256GB of RAM and SSDs? To: Merlin Moncure Cc: Kaixi Luo , 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 Thu, Jul 7, 2016 at 10:27 AM, Merlin Moncure wrote: > On Wed, Jul 6, 2016 at 4:48 PM, Scott Marlowe wrote: >> On Wed, Jul 6, 2016 at 12:13 PM, Merlin Moncure wrote: >>> 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. >> >> Interesting. We found our best performance with a RAID-5 of 10 800GB >> SSDs (Intel 3500/3700 series) that we got MUCH faster performance with >> all write caching turned off on our LSI MEgaRAID controllers. We went >> from 3 to 4ktps to 15 to 18ktps. And after a year of hard use we still >> show ~90% life left (these machines handle thousands of writes per >> second in real use) It could be that the caching was getting in the >> way of RAID calcs or some other issue. With RAID-1 I have no clue what >> the performance will be with write cache on or off. > > Right -- by that I meant disabling the write back cache on the drive > itself, so that all writes are immediately flushed. Disabling write > back on the raid controller should be the right choice; each of these > drives essentially is a 'caching raid controller' for all intents and > purposes. Hardware raid controllers are engineered around performance > and reliability assumptions that are no longer correct in an SSD > world. Personally I would have plugged the drives directly to the > motherboard (assuming it's a got enough lanes) and mounted the raid > against mdadm and compared. Oh yeah definitely. And yea we've found that mdadm and raw HBAs work better than most RAID controllers for SSDs. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance