Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ebGZj-0008MF-0R for pgsql-performance@arkaria.postgresql.org; Tue, 16 Jan 2018 02:02:07 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ebGZi-0002hx-FX for pgsql-performance@arkaria.postgresql.org; Tue, 16 Jan 2018 02:02:06 +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 1ebGWE-0005Tf-V8 for pgsql-performance@lists.postgresql.org; Tue, 16 Jan 2018 01:58:31 +0000 Received: from mail-it0-x22d.google.com ([2607:f8b0:4001:c0b::22d]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1ebGWC-00035t-3O for pgsql-performance@lists.postgresql.org; Tue, 16 Jan 2018 01:58:29 +0000 Received: by mail-it0-x22d.google.com with SMTP id e1so2918282ita.0 for ; Mon, 15 Jan 2018 17:58:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=YcuaJvv2KbcBzSDPN4I4DT99mtBdWiqqZGEYQvfOaEk=; b=08gNsTFwm+6lvs1KuVl2L21h7zIhixQ24eJ/BGeo8gZnpybh+AoDsSX8nTGVMaIG6V byyhMR5numfG1VXG5qPrsscPXgf0BWqI/yOVCRULbAvbpKV5rFsDbVdzCM0yjb1+fmn/ KvDAKSfYRYjuRa6MqDaCvUnGcv+S4PLtu05S5aPMB/Gktc2xo2IJ4mVsrsmQTWeWv1tO JS6Sr2v6x/SfymqXfI6k/HWixd13JaQDvcQB5styfAKRtsMNNoy8a0vwBEzDNjFAxAUN /oL9EsyqUcVuvLtO2IESA6mN+pedUKNdpYQu3va1MIC300sN+sLXEzuiBhhHJIO1KQq3 ucCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=YcuaJvv2KbcBzSDPN4I4DT99mtBdWiqqZGEYQvfOaEk=; b=LioXHvHlULTuFbsfxmUEwjdqZpyKdSiIB9zF0Rx3F/CF0PQrTzbCIhts4cmbLHtr4/ r1A1qUUCZLP3o1k9e823xF/58E1xBrW8NRCnLV26H9qof2DOnE0JNIBu8CxwGRyUpDL4 Mw9BA4r8VJfJaiI2o0de+j1OV2EEUja+GDDpxqvIbQIMsA1DtRMOnJo1FvcgDofxR5GE vE9WuP2mPykiY0Z2eFaQ/zfdnLeJFaxiDXj5b3BLOdNoC9sMRy/hMx+cHqUidWfKaYGC x/zMoFqM2QWi4whzLqKp9g3nCe1Ld4jIS0cOZaDhgrZRWaoscpzS/EZlJsQQgUQW0Vzv KZBA== X-Gm-Message-State: AKwxytfSbQoUzrg+Hyg8uwfggvjousVwnnlT/VsskRZijsVW+2UAb5fu Pt2Mi4qZJdT3qGV1foFOReQjDQ== X-Google-Smtp-Source: ACJfBotQ/zvZzKKpo7yT14exXT9ngfhgtGEgpA0zzSHPMwPy99FfGSCzH+gW3OhDJvBR+jZxWmaHbA== X-Received: by 10.36.211.132 with SMTP id n126mr15410386itg.12.1516067906644; Mon, 15 Jan 2018 17:58:26 -0800 (PST) Received: from pryzbyj (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id j194sm612061ite.7.2018.01.15.17.58.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Jan 2018 17:58:26 -0800 (PST) Received: by pryzbyj (Postfix, from userid 1000) id 5E1D9800FD9; Mon, 15 Jan 2018 19:58:25 -0600 (CST) Date: Mon, 15 Jan 2018 19:58:25 -0600 From: Justin Pryzby To: Neto pr Cc: Fernando Hevia , "Georg H." , pgsql-performance@lists.postgresql.org Subject: Re: HDD vs SSD without explanation Message-ID: <20180116015825.GB3905@telsasoft.com> References: <0b5a8964-132b-f41f-11d6-5cc6bf0cc551@silentrunner.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Mon, Jan 15, 2018 at 05:19:59PM -0800, Neto pr wrote: > >> Can you reproduce the speed difference using dd ? > >> time sudo dd if=/dev/sdX of=/dev/null bs=1M count=32K > >> skip=$((128*$RANDOM/32)) # set bs to optimal_io_size > > > > Still I would have expected somewhat similar results in the outcome, so yes, > > it is weird that the SAS drive doubles the SSD performance. That is why I > > think there must be something else going on during your tests on the SSD > > server. It can also be that the SSD isn't working properly or you are > > running an suboptimal OS+server+controller configuration for the drive. > > Ok. > > Can you help me to analyze the output of the command: dd if=/dev/sdX > of=/dev/null bs=1M count=32K skip=$((128*$RANDOM/32)) # set bs to > optimal_io_size You should run the "dd" without the DB or anything else using the drive. That gets peformance of the drive, without the DB. You should probably rerun the "dd" command using /dev/sdb1 if there's an partition table on top (??). I'm still wondering about these: On Sun, Jan 14, 2018 at 09:09:41PM -0600, Justin Pryzby wrote: > What about sdb partitions/FS? > > > readahead? blockdev --getra > > > > If you're running under linux, maybe you can just send the output of: > > > for a in /sys/block/sdX/queue/*; do echo "$a `cat $a`"; done > > > or: tail /sys/block/sdX/queue/{minimum_io_size,optimal_io_size,read_ahead_kb,scheduler,rotational,max_sectors_kb,logical_block_size,physical_block_size} Justin