Date: Fri, 3 Jul 2020 13:18:13 -0700 From: =?utf-8?Q?Pawe=C5=82_Jakub_Dawidek?= <pawel@dawidek.net> To: Alan Somers <asomers@freebsd.org> Cc: freebsd-geom@freebsd.org Subject: Re: Single-threaded bottleneck in geli Message-ID: <48AB9191-5984-4BE0-BF98-7548424D06BF@dawidek.net> In-Reply-To: <CAOtMX2hFaNCmwkuhfWWqNwACETtomnJroTC1_giOO_iFj0SKFQ@mail.gmail.com> References: <CAOtMX2hFaNCmwkuhfWWqNwACETtomnJroTC1_giOO_iFj0SKFQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Alan,
why do you think it will hurt single-threaded performance?
--=20
Pawe=C5=82 Jakub Dawidek
> On Jul 3, 2020, at 12:30, Alan Somers <asomers@freebsd.org> wrote:
>=20
> =EF=BB=BFI'm using geli, gmultipath, and ZFS on a large system, with hundr=
eds of
> drives. What I'm seeing is that under at least some workloads, the overal=
l
> performance is limited by the single geom kernel process. procstat and
> kgdb aren't much help in telling exactly why this process is using so much=
> CPU, but it certainly must be related to the fact that over 15,000 IOPs ar=
e
> going through that thread. What can I do to improve this situation? Woul=
d
> it make sense to enable direct dispatch for geli? That would hurt
> single-threaded performance, but probably improve performance for highly
> multithreaded workloads like mine.
>=20
> Example top output:
> PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND
> 13 root -8 - 0B 96K CPU46 46 82.7H 70.54%
> geom{g_down}
> 13 root -8 - 0B 96K - 9 35.5H 25.32%
> geom{g_up}
>=20
> -Alan
> _______________________________________________
> freebsd-geom@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-geom
> To unsubscribe, send any mail to "freebsd-geom-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48AB9191-5984-4BE0-BF98-7548424D06BF>