Date: Wed, 22 Mar 2017 22:25:24 +0100 From: "O. Hartmann" <o.hartmann@walstatt.org> To: Michael Gmelin <freebsd@grem.de> Cc: "O. Hartmann" <ohartmann@walstatt.org>, FreeBSD CURRENT <freebsd-current@freebsd.org> Subject: Re: CURRENT: slow like crap! ZFS scrubbing and ports update > 25 min Message-ID: <20170322222524.2db39c65@thor.intern.walstatt.dynvpn.de> In-Reply-To: <70346774-2E34-49CA-8B62-497BD346CBC8@grem.de> References: <20170322210225.511da375@thor.intern.walstatt.dynvpn.de> <70346774-2E34-49CA-8B62-497BD346CBC8@grem.de>
next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_/k0xYkZg4PbQTRQ0eQ5S1Va3
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Am Wed, 22 Mar 2017 21:10:51 +0100
Michael Gmelin <freebsd@grem.de> schrieb:
> > On 22 Mar 2017, at 21:02, O. Hartmann <ohartmann@walstatt.org> wrote:
> >=20
> > CURRENT (FreeBSD 12.0-CURRENT #82 r315720: Wed Mar 22 18:49:28 CET 2017=
amd64) is
> > annoyingly slow! While scrubbing is working on my 12 GB ZFS volume,
> > updating /usr/ports takes >25 min(!). That is an absolute record now.
> >=20
> > I do an almost daily update of world and ports tree and have periodic =
scrubbing ZFS
> > volumes every 35 days, as it is defined in /etc/defaults. Prts tree has=
n't grown much,
> > the content of the ZFS volume hasn't changed much (~ 100 GB, its fill i=
s about 4 TB
> > now) and this is now for ~ 2 years constant.=20
> >=20
> > I've experienced before that while scrubbing the ZFS volume, some opera=
tions, even the
> > update of /usr/ports which resides on that ZFS RAIDZ volume, takes a bi=
t longer than
> > usual - but never that long like now!
> >=20
> > Another box is quite unusable while it is scrubbing and it has been usa=
ble times
> > before. The change is dramatic ...
> > =20
>=20
> What do "zpool list", "gstat" and "zpool status" show?
>=20
>=20
>=20
zpool list:
NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTRO=
OT
TANK00 10.9T 5.45T 5.42T - 7% 50% 1.58x ONLINE -
Deduplication is off right now, I had one ZFS filesystem with dedup enabled
gstat: not shown here, but the drives comprise the volume (4x 3 TB) show 10=
0% busy each,
but one drive is always a bit off (by 10% lower) and this drive is walking =
through all
four drives ada2, ada3, ada4 and ada5. Nothing unusual in that situation. B=
ut the
throughput is incredible low, for example ada4:
L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name
2 174 174 1307 11.4 0 0 0.0 99.4| ada4
kBps (kilo Bits per second I presume) are peaking at ~ 4800 - 5000. On anot=
her bos, this
is ~ 20x higher! Most time, kBps r and w stay at ~ 500 -600.
zpool status:
pool: TANK00
state: ONLINE
scan: scrub in progress since Wed Mar 22 19:12:41 2017
167G scanned out of 5.62T at 15.9M/s, 99h46m to go
0 repaired, 2.91% done
config:
NAME STATE READ WRITE CKSUM
TANK00 ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
gpt/tank00 ONLINE 0 0 0
gpt/tank01 ONLINE 0 0 0
gpt/tank02 ONLINE 0 0 0
gpt/tank03 ONLINE 0 0 0
logs
gpt/zil00 ONLINE 0 0 0
cache
gpt/l2arc00 ONLINE 0 0 0
errors: No known data errors
Here are the incredible low numbers more clear. Usually, the hardware is ca=
pable of doing
~ 280 - 300 MBytes/s. It is stuck for hours at 15 - 16 MBytes/s.
--Sig_/k0xYkZg4PbQTRQ0eQ5S1Va3
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature
-----BEGIN PGP SIGNATURE-----
iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWNLrxAAKCRDS528fyFhY
lDgaAf4901djZ+7HsfgS9kDrGcWXKwMO14DRCRFHla8MHLv1eTp7XEkYzTX3W1Yn
5Cc89j2XT+HqAivLkfOTs8KuqD3KAgCde4j6MFK8ypzuZgBZh5ILsuNDEyv/NXcx
GTvBUJLU4vlDIRWrytlPdSMxI748DQaLb8xsSurUxTdHDLrGuMg8
=V+Mn
-----END PGP SIGNATURE-----
--Sig_/k0xYkZg4PbQTRQ0eQ5S1Va3--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170322222524.2db39c65>