Date: Wed, 05 Mar 2014 08:17:28 -0600 From: Karl Denninger <karl@denninger.net> To: freebsd-fs@freebsd.org Subject: Re: Is LZ4 compression of the ZFS L2ARC available in any RELEASE/STABLE? Message-ID: <531731F8.1050000@denninger.net> In-Reply-To: <CAJ7kQyEp208XKt3CaiBufiB%2Bg_CHAkUgzAzVdX_6Gx2WyW1ENg@mail.gmail.com> References: <CAJ7kQyGTOuynOoLukXbP2E6GPKRiBWx8_mLEchk90WDKO%2Bo-SA@mail.gmail.com> <53157CC2.8080107@FreeBSD.org> <CAJ7kQyGQjf_WbY64bLVX=YfmJUfAd8i22kVbVhZhEWPMg7bbQw@mail.gmail.com> <5315D446.3040701@freebsd.org> <CAJ7kQyFf19Un_TS=kW=T21HT%2BoabhsUhJij5oixQ2_uh0LvHRA@mail.gmail.com> <alpine.GSO.2.01.1403042037290.1717@freddy.simplesystems.org> <CAJ7kQyEp208XKt3CaiBufiB%2Bg_CHAkUgzAzVdX_6Gx2WyW1ENg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] It probably won't matter all that much. You need to profile this but you can get a decent idea what's going on from sysstat or iostat; look at the transaction count, size per transaction and percentage of time the disks are busy. I bet you find low transaction size, moderate count and very high disk busy percentages, which points to lots of head movement on an average basis compared against bytes moved. That's the paradigm where spinning rust loses, basically, and the only answers are to spread the I/O across more spindles so you get more positioner economy, go to faster-rotating drives with faster seek times or move to SSDs. If your I/O pattern is as I suspect the first thing to do is get the L2ARC off the rest of the pool's disks as that de-couples that I/O from the actual data storage. In mixed, small I/O environments this frequently will double total throughput and it costs you just one spindle, and it can be a small one too as the L2ARC requirement is modest. Making that L2ARC a SSD is an option but beware of using cheap ones there as fault-tolerance rules apply to L2ARC as they do to data disks (this is not true for a cache drive which is ignored if it posts errors and results in no data loss.) Presuming that doesn't provide enough boost the next logical move is to consider putting the DBMS on SSDs itself. That completely removes positioning latency and will result in a massive speed increase. On 3/5/2014 1:17 AM, Olav Gjerde wrote: > Currently I've set the recordsize to 8k, however I'm thinking maybe a > recordsize of 4k may more optimal? > This is because the compressratio with LZ4 is around 2.5 and this value has > been constant for all my data while growing from a few megabytes to a > tenfold of gigabytes. > Maybe something I should play with to see if it makes a difference. > > > On Wed, Mar 5, 2014 at 3:40 AM, Bob Friesenhahn < > bfriesen@simple.dallas.tx.us> wrote: > >> On Tue, 4 Mar 2014, Olav Gjerde wrote: >> >> I managed to mess up who I replied to and Matthew replied back with a good >>> answer which I think didn't reach the mailing list. >>> >>> I actually have a problem with query performance in one of my databases >>> related to running PostgreSQL on ZFS. Which is why I'm so interested in >>> compression for the L2ARC Cache. The problem is random IO read were >>> creating a report were I aggregate 75000 rows takes 30 minutes!!! The >>> table >>> that I query has 400 million rows though. >>> The dataset easily fit in memory, so if I run the same query again it >>> takes >>> less than a second. >>> >> Make sure that your database is on a filesystem with zfs block-size >> matching the database block-size (rather than 128K). Otherwise far more >> data may be read than needed, and likewise, writes may result in writing >> far more data than needed. >> >> Regardless, L2ARC on SSD is a very good idea for this case. >> >> Bob >> -- >> Bob Friesenhahn >> bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ >> GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ >> > > -- -- Karl karl@denninger.net [-- Attachment #2 --] 0 *H 01 0 + 0 *H O0K030 *H 01 0 UUS10UFlorida10U Niceville10U Cuda Systems LLC1 0UCuda Systems LLC CA1/0- *H customer-service@cudasystems.net0 130824190344Z 180823190344Z0[1 0 UUS10UFlorida10UKarl Denninger1!0 *H karl@denninger.net0"0 *H 0 bi՞] MNԿawx?`)'ҴcWgR@BlWh+ u}ApdCF JVй~FOL }EW^bچYp3K& ׂ(R lxڝ.xz?6 &nsJ +1v9 v/( kqĪp[vjcK%fϻe?iq]z lyzFO'ppdX//Lw(3 JI A*S#՟H[f|CGqJKoo y.oEuOw$ /섀$삻J9b|A P~8]D1YI<"""Y^T2iQ2 b yH)] Ƶ0y$ _N 6XqMC 9 XgώjGTP"#nˋ"Bk1 00 U 0 0 `HB0 U 0, `HB OpenSSL Generated Certificate0 U |8 ˴d[20 U #0]Af4 U3x&^"408 `HB+)https://cudasystems.net:11443/revoked.crl0 *H gBwH] j\x`( &gW32"Uf^. ^Iϱ k!DQA g{(w /)\N'[ oRW @C HO>)XrTNɘ!u`xt5(=f\-l3<@C6mnhv##1ŃbH͍_Nq aʷ?rk$^9TIa!kh,D -ct1 0001 0 UUS10UFlorida10U Niceville10U Cuda Systems LLC1 0UCuda Systems LLC CA1/0- *H customer-service@cudasystems.net0 + ;0 *H 1 *H 0 *H 1 140305141728Z0# *H 1f$0l *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 customer-service@cudasystems.net0 *H 101 0 UUS10UFlorida10U Niceville10U Cuda Systems LLC1 0UCuda Systems LLC CA1/0- *H customer-service@cudasystems.net0 *H wۅ{>e Uv]Nw!e ̻|]7JP+)ƹTPV Ao$=$3.A|s_`VS70N(bm )j2*YL#Ϟ&g_7fm1j['M洄,ϰjb!~ӓIs +CI%6}9Pg=JIP*4D c}KsRޏ PN=k(ٽe]4[_ $p aAT47VjdGcPm&x$My"l/:9Sȑ* JSmQԌ)GZ"9E Ï9|yyb1W]s7T x鳦EB R%kV0ǖ4 T @%meHջ[ =&^wO)M ,k%>>bkIejkh +eŊ\ l
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?531731F8.1050000>