Re: ZFS RAIDZ1: resilvering at <17.3M/s => abyssal slow ...

From: Adam Vande More <amvandemore_at_gmail.com>
Date: Thu, 14 Dec 2017 09:28:08 -0600
On Thu, Dec 14, 2017 at 8:52 AM, O. Hartmann <ohartmann_at_walstatt.org> wrote:

> Am Thu, 14 Dec 2017 15:46:17 +0100
> Dimitry Andric <dim_at_FreeBSD.org> schrieb:
>
> > On 14 Dec 2017, at 14:43, O. Hartmann <ohartmann_at_walstatt.org> wrote:
> > >
> > > Am Thu, 14 Dec 2017 14:09:39 +0100
> > > Daniel Nebdal <dnebdal_at_gmail.com> schrieb:
> > >> On Thu, Dec 14, 2017 at 12:48 PM, O. Hartmann <ohartmann_at_walstatt.org>
> wrote:
> > >>> I just started the rebuild/resilvering process and watch the pool
> crwaling at ~ 18
> > >>> MB/s. At the moment, there is no load on the array, the host is a
> IvyBridge XEON
> > >>> with 4 core/8 threads and 3,4 GHz and 16 GB of RAM. The HDDs are
> attached to a
> > >>> on-board SATA II (300 MB/s max) Intel chip - this just for the
> record.
> > >>>
> > >>> Recently, I switch on the "sync" attribute on most of the defined
> pools's zfs
> > >>> filesystems
> > >>> - I also use a SSD for ZIL/L2ARC caching, but it seems to be unused
> recently in
> > >>> FreeBSD CURRENT's ZFS - this from a observers perspective only.
> > >>>
> > >>> When scrubbing, I see recently also reduced performance on the pool,
> so I'm
> > >>> wondering about the low throughput at the very moment when
> resilvering is in
> > >>> progress.
> > >>>
> > >>> If the "perspective" of "zpool status" is correct, then I have to
> wait after two
> > >>> hours for another 100 hours - ~ 4 days? Ups ... I think there is
> something badly
> > >>> misconfigured or missing.
> > ...
> > >> This is kind of to be expected - for whatever reason, resilvers seem
> > >> to go super slow at first and then speed up significantly. Just don't
> > >> ask me how long "at first" is - I'd give it several (more) hours.
> >
> > Hopefully this will get better in the future, please read:
> >
> > http://open-zfs.org/wiki/Scrub/Resilver_Performance
> >
> > -Dimitry
> >
>
> It has already been started to become better ;-)
>
> After a while now, the throughput is at 128 MBytes/s and the estimated
> time decreased to
> ~ 8 h now - that is much more appreciable than 4 days ;-)
>

If you are viewing the rate with zpool status, I don't think that is a
close to realtime rate.  I don't know of a way to check that either.

-- 
Adam
Received on Thu Dec 14 2017 - 14:28:10 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:14 UTC