Date: Tue, 20 Jun 2017 12:58:21 -0500 From: Karl Denninger <karl@denninger.net> To: "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org> Subject: Re: FreeBSD 11.1 Beta 2 ZFS performance degradation on SSDs Message-ID: <4276a57b-5974-0d4b-c535-ea11c491b46f@denninger.net> In-Reply-To: <2d8a525e5355406aa7b8bf6690101008@DM2PR58MB013.032d.mgd.msft.net> References: <2d8a525e5355406aa7b8bf6690101008@DM2PR58MB013.032d.mgd.msft.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] On 6/20/2017 12:29, Caza, Aaron wrote: >> -----Original Message----- >> From: Karl Denninger [mailto:karl@denninger.net] >> Sent: Monday, June 19, 2017 7:28 PM >> To: freebsd-fs@freebsd.org >> Subject: Re: FreeBSD 11.1 Beta 2 ZFS performance degradation on SSDs >> >> 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]/ > Thanks for the suggestions Karl. I'll investigate further after I resolve this performance degradation issue I'm experiencing. I recently read another FreeBSD+ZFS+PostgreSQL user's Scale15x presentation, PostgreZFS, Sean Chittenden if I recall correctly, who also advised lz4 compression + 16K page size rather than 8K with PostgreZFS. > > With regards to my performance woes, I was originally using PostgreSQL in my posts to freebsd-hackers@freebsd.org but started using 'dd' to remove it as a point of contention. In attempting to resolve this issue, I tried using your patch to PR 187594 (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187594). Took a bit of effort to find a revision of FreeBSD 10 Stable to which your FreeBSD10 patch would both apply and compile cleanly; however, it didn't resolve the issue I'm experiencing. I would not have expected my PR to impact this issue. I suspicious of a drive firmware interaction with your I/O pattern; SSDs are somewhat-notorious for having that come up under certain workloads that involve a lot of writes. -- Karl Denninger karl@denninger.net <mailto:karl@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/ [-- Attachment #2 --] 0 *H 010 `He 0 *H \0X0@=0 *H 01 0 UUS10UFlorida10U Niceville10U Cuda Systems LLC1 0UCuda Systems LLC CA1"0 *H Cuda Systems LLC CA0 161218194535Z 211217194535Z0W1 0 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<m4 BeSet| l2m 6iO{wv + aH Xˈ5=~é*C!?uJr3tb' 3`Oe)üLxt&3N526 llU .|Cp[l? 007++0)0'+0http://cudasystems.net:88880 U 0 0 `HB0 U 0, `HB OpenSSL Generated Certificate0 U /Zi 0GhG0 U #0$q}ݽʒm50 U 0karl@denninger.net0 *H b% X% gwq Ɂэr K[DMJ35W6 sz8d|qB2Cyw2PbV} â[!W{HD7oD.TZ'w6~g( -,]R8P{*[f<1=7 jGj9铚~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|Za1nZ5TuPvW|#G+ DZpI7S'n0 haGa@vZ e|]Cu+))vRyY10001 0 UUS10UFlorida10U Niceville10U Cuda Systems LLC1 0UCuda Systems LLC CA1"0 *H Cuda Systems LLC CA=0 `He M0 *H 1 *H 0 *H 1 170620175821Z0O *H 1B@L~p/B'̡0;ucrLG#BqM%r9[RP|(bI0l *H 1_0]0 `He*0 `He0 *H 0*H 0 *H @0+0 *H (0 +71001 0 UUS10UFlorida10U Niceville10U Cuda Systems LLC1 0UCuda Systems LLC CA1"0 *H Cuda Systems LLC CA=0 *H 101 0 UUS10UFlorida10U Niceville10U Cuda Systems LLC1 0UCuda Systems LLC CA1"0 *H Cuda Systems LLC CA=0 *H v: 5UPwzq$k|Xw2al+wӪ | t+iExTw>g/Μѥ9{SؤGA;Z pHڻPWNؤ>Yg829 d8ΕxY;RS^aQ@<θ.aϫgBLȲ׳N/{0ZIYf %59E&ė.}t#|IL ( =л(7KYsGӃq%k+cx1VuӽζNT[64]QM9=Ē`n yX&lGWy$IP: ]mժXke~aAd`DKtrATګ)QV A[Q .Rbv&k9͕3ɳ?Z&\ޢۃ5dmu @ S؈c{R~W7 <jGk
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4276a57b-5974-0d4b-c535-ea11c491b46f>