Date: Tue, 5 Jan 2016 06:51:09 -0500 From: Tom Curry <thomasrcurry@gmail.com> To: Paul Kraus <paul@kraus-haus.org> Cc: FreeBSD Filesystems <freebsd-fs@freebsd.org>, "Mikhail T." <mi+thun@aldan.algebra.com> Subject: Re: NFS reads vs. writes Message-ID: <CAGtEZUDmAk8R5m=6VUiYZb%2BHp-UsS9W4GNae1wy=7DnuM1cU3A@mail.gmail.com> In-Reply-To: <D0AC7351-25DC-478C-981E-E32B1F5E353F@kraus-haus.org> References: <8291bb85-bd01-4c8c-80f7-2adcf9947366@email.android.com> <5688D3C1.90301@aldan.algebra.com> <495055121.147587416.1451871433217.JavaMail.zimbra@uoguelph.ca> <568A047B.1010000@aldan.algebra.com> <CAGtEZUD28UZDYyHtHtzXgys%2Brpv_37u4fotwR%2BqZLc1%2BtK0dwA@mail.gmail.com> <D0AC7351-25DC-478C-981E-E32B1F5E353F@kraus-haus.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jan 4, 2016 at 10:06 PM, Paul Kraus <paul@kraus-haus.org> wrote: > On Jan 4, 2016, at 18:58, Tom Curry <thomasrcurry@gmail.com> wrote: > > > SSDs are so fast for three main reasons: low latency, large dram buffer= s, > > and parallel workloads. Only one of these is of any benefit (latency) a= s > a > > SLOG. Unfortunately that particular metric is not usually advertised in > > consumer SSDs where the benchmarks they use to tout 90,000 random write > > iops consist of massively concurrent, highly compressible, short lived > > bursts of data. Add that drive as a SLOG and the onboard dram may as we= ll > > not even exist, and queue depths count for nothing. It will be lucky to > > pull 2,000 IOPS. Once you start adding in ZFS features like checksums a= nd > > compression, or network latency in the case of NFS that 2,000 number > starts > > to drop even more. > > I have a file server that I am going through the task of optimizing for > NFS traffic (to store VM images). My first attempt, because I knew about > the need for an SSD based SLOG for the ZIL was using a pair of Intel 535 > series SSD=E2=80=99s. The performance with the SLOG/ZIL on the SSD was _w= orse_. > Turns out that those SSD=E2=80=99s have poor small block (8 KB) random wr= ite > performance (not well advertised). So I asked for advice for choosing a > _fast_ SSD on the OpenZFS list and had a number of people recommend the > Intel DC-Sxxxx series of SSDs. > > Based on the very thorough data sheets, I am going with a pair of DC-S3710 > 200 GB SSDs. Once I get them in and configured I=E2=80=99ll post results. > > That is an excellent choice, I'm looking forward to the results. They have capacitors for power loss protection which means its safe to allow them to use their on-board dram cache. Wouldn't it be great if we could tell ZFS to not flush the cache on log devices via sysctl or some other means? Change nothing else about how sync operations occur. Unless I'm missing something this would provide the same level of protection but allow for greatly improved performance of the SSD. > Note that my zpool consists of 5 top level vdevs each made up of a 3-way > mirror. So I am striping writes across 5 columns. I am using 500 GB WD RE > series drives leaving the ZIL on the primary vdevs was _faster_ than addi= ng > the consumer SSD as SLOG for NFS writes. > > -- > Paul Kraus > paul@kraus-haus.org > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGtEZUDmAk8R5m=6VUiYZb%2BHp-UsS9W4GNae1wy=7DnuM1cU3A>