Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 19 Jun 2017 20:27:50 -0500
From:      Karl Denninger <karl@denninger.net>
To:        freebsd-fs@freebsd.org
Subject:   Re: FreeBSD 11.1 Beta 2 ZFS performance degradation on SSDs
Message-ID:  <5033585e-591e-99b5-c14e-0c0fb70f63fb@denninger.net>
In-Reply-To: <431d958c658a408d8bfd4c574a565439@DM2PR58MB013.032d.mgd.msft.net>

index | next in thread | previous in thread | raw e-mail

[-- Attachment #1 --]
Just one note below...

On 6/19/2017 19:57, Caza, Aaron wrote:
>
> Note that file /testdb/test is 16GB, twice the size of ram available in this system.  The /testdb directory is a ZFS file system with recordsize=8k, chosen as ultimately it's intended to host a PostgreSQL database which uses an 8k page size.
Do not make this assumption blindly.  Yes, I know the docs say to set
recordsize=8k but this is something you need to benchmark against your
actual working data set.

MANY Postgres workloads are MUCH faster (2x or more!) if you use a
default page size and lz4 compression -- including one I have in
production and have extensively benchmarked.  The difference is NOT small.
....

zroot/ticker  compressratio         1.53x                         -
zroot/ticker  mounted               yes                           -
zroot/ticker  quota                 none                          default
zroot/ticker  reservation           none                          default
zroot/ticker  recordsize            128K                          default
zroot/ticker  mountpoint            /usr/local/pgsql/data-ticker  local
zroot/ticker  sharenfs              off                           default
zroot/ticker  checksum              fletcher4                    
inherited from zroot
zroot/ticker  compression           lz4                          
inherited from zroot
zroot/ticker  atime                 off                          
inherited from zroot

You may also want to consider setting logbias=throughput.  In some cases
the improvement there can be quite material as well -- depending on the
insert/update traffic to the database in question.

-- 
Karl Denninger
karl@denninger.net <mailto:karl@denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/

[-- Attachment #2 --]
0	*H
010
	`He0	*H
\0X0@=0
	*H
010	UUS10UFlorida10U	Niceville10U
Cuda Systems LLC10UCuda Systems LLC CA1"0 	*H
	Cuda Systems LLC CA0
161218194535Z
211217194535Z0W10	UUS10UFlorida10U
Cuda Systems LLC10Ukarl@denninger.net0"0
	*H
0
͍fd`1ie6";fSz`5¹/?{=Ӵowjħ_fnӴMG\ҢҖ4ib}>@mJo&mM;
Q9U cj]p퐆W.2E=
^¢tzĄ'5i7_`~#dY
`]R]N%R}EXzqV@[oN	T>5AwYˡA"\v&YG]+($p:M,T?=mJkMљg*ym
L!J[./d׷?W^LysD'1
+V'~{-SSX=q-f=%&V<m4BeSet|
l2m 6iO{wv
+aHXˈ5=~é*C!?uJr3tb'3`Oe)üLxt&3N526llU
.|Cp[l?007++0)0'+0http://cudasystems.net:88880	U00	`HB0U0,	`HB
OpenSSL Generated Certificate0U/Zi
0GhG0U#0$q}ݽʒm50U0karl@denninger.net0
	*H
b%X%gwq	
ɁэrK[DMJ35W6
sz8d|qB2Cyw2PbV}
â[!W{HD7oD.TZ'w6~g( -,]R8P{*[f<1=7jGj9铚~3f2AʺN	k~@vz^j(>ͺyh2y{/9}4.45#S|<fW!.,Bss*Q+h=}l@	"q "M&6J5*,G {hɫjbNgǠ.ЃXȶ4$O.5evHlZba!4eE!x|Za1򹿈nZ5TuPvW|#G+	DZpI7S'n0 haGa@vZ	e|]Cu+))vRyY100010	UUS10UFlorida10U	Niceville10U
Cuda Systems LLC10UCuda Systems LLC CA1"0 	*H
	Cuda Systems LLC CA=0
	`HeM0	*H
	1	*H
0	*H
	1
170620012750Z0O	*H
	1B@a5OxDCfcLexPr^<X:&>}gyh20l	*H
	1_0]0	`He*0	`He0
*H
0*H
0
*H
@0+0
*H
(0	+710010	UUS10UFlorida10U	Niceville10U
Cuda Systems LLC10UCuda Systems LLC CA1"0 	*H
	Cuda Systems LLC CA=0*H
	1010	UUS10UFlorida10U	Niceville10U
Cuda Systems LLC10UCuda Systems LLC CA1"0 	*H
	Cuda Systems LLC CA=0
	*H
74i7baXu~WB7}
h#T~8Eh7
#Y@AlCT:+ڬw+X?t
Ɇ
p>Itv<>DvXS_oԚ}.H{.a+C\_ 5qB`d͜zx`qeXմeㅺ-C~Yv܄=6-vҠ9R^4(\t8
&[ԑa{,W
7aGA?ՅR0/KTY:C]8-LIٙ@~|@h3ڻKY@I?ۀP̛V΍6V)W[VVHwW5=3ߑ¤^E^<߆ɣOE,'i	ai[d/rv*ѹ/c((-M?;K\ƮQ
home | help

Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5033585e-591e-99b5-c14e-0c0fb70f63fb>