Date: Sun, 3 Oct 2010 19:06:20 -0700 From: Artem Belevich <fbsdlist@src.cx> To: Dan Langille <dan@langille.org> Cc: freebsd-stable <freebsd-stable@freebsd.org> Subject: Re: zfs send/receive: is this slow? Message-ID: <AANLkTi=-JcAXW3wfJZoQMoQX3885GFpDAJ2Pa3OLKSUE@mail.gmail.com> In-Reply-To: <4CA929A8.6000708@langille.org> References: <a263c3beaeb0fa3acd82650775e31ee3.squirrel@nyi.unixathome.org> <45cfd27021fb93f9b0877a1596089776.squirrel@nyi.unixathome.org> <AANLkTik0aTDDSNRUBvfX5sMfhW%2B-nfSV9Q89v%2BeJo0ov@mail.gmail.com> <4C511EF8-591C-4BB9-B7AA-30D5C3DDC0FF@langille.org> <AANLkTinyHZ1r39AYrV_Wwc2H3B=xMv3vbeDLY2Gc%2Bkez@mail.gmail.com> <4CA68BBD.6060601@langille.org> <4CA929A8.6000708@langille.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Oct 3, 2010 at 6:11 PM, Dan Langille <dan@langille.org> wrote: > I'm rerunning my test after I had a drive go offline[1]. =A0But I'm not > getting anything like the previous test: > > time zfs send storage/bacula@transfer | mbuffer | zfs receive > storage/compressed/bacula-buffer > > $ zpool iostat 10 10 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 capacity =A0 =A0 operations =A0 =A0bandwidth > pool =A0 =A0 =A0 =A0 used =A0avail =A0 read =A0write =A0 read =A0write > ---------- =A0----- =A0----- =A0----- =A0----- =A0----- =A0----- > storage =A0 =A0 6.83T =A05.86T =A0 =A0 =A08 =A0 =A0 31 =A01.00M =A02.11M > storage =A0 =A0 6.83T =A05.86T =A0 =A0207 =A0 =A0481 =A025.7M =A017.8M It may be worth checking individual disk activity using gstat -f 'da.$' Some time back I had one drive that was noticeably slower than the rest of the drives in RAID-Z2 vdev and was holding everything back. SMART looked OK, there were no obvious errors and yet performance was much worse than what I'd expect. gstat clearly showed that one drive was almost constantly busy with much lower number of reads and writes per second than its peers. Perhaps previously fast transfer rates were due to caching effects. I.e. if all metadata already made it into ARC, subsequent "zfs send" commands would avoid a lot of random seeks and would show much better throughput. --Artem
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTi=-JcAXW3wfJZoQMoQX3885GFpDAJ2Pa3OLKSUE>