GELI strangeness with gstat
John-Mark Gurney
jmg at funkthat.com
Tue Nov 28 07:08:13 UTC 2017
Pete French wrote this message on Mon, Nov 27, 2017 at 13:08 +0000:
> So, I have a set of machines running rul disc
> encryption with GELI. The output from gstat on
> an example one looks something like this:
>
> 0 27 3 100 0.4 16 100 0.1 1.1| ada0p4
> 0 27 3 100 0.9 16 100 0.2 1.3| ada0p4.eli
>
> I uapgraded a couple of thme to much faster CPUs - the output then
> started looking like this:
>
> 0 146 0 0 0.0 125 604 0.1 5.7| ada0p4
> 2 146 0 0 0.0 125 604 0.1 104.3| ada0p4.eli
>
> ...so the .eli device is now running at 100% despite
> the underlying disc only being about 6% busy.
>
> This was software encryption - my assumption was that the faster COU's
> were now enabling me to overload the encryption somehow, so I enabled
> AES-NI on the COU. Now I have hardware encryption. But the output from gstat
> still looks the same.
If you just did a kldload aesni, but did not reattach the geli device,
then you are still using software encryption... You should see something
like this:
GEOM_ELI: Device gpt/werner.eli created.
GEOM_ELI: Encryption: AES-XTS 256
GEOM_ELI: Crypto: hardware
if you are using AES-NI...
Also, what version of FreeBSD are you using? If you're using pre-10.0-R,
the performance increase from using AES-NI is only marginal...
The above does make it look like you're disks are CPU bound by the
encryption...
> Whats going on here ? Its very ouzzlking. What is even odder is that these
> machines are ina HAST pair, and the secondary side looks fine - i.e. only
> a few percent busy on the disc and the encrypted device. If I sap
> roles then the efect persists - the HAST primary has a massively busy
> ELI device.
>
> I realise the oprimary will be doing reads as well as writes, but as you can
> see from the snapshot above, its not singificany compares to the
> writes, and the effect is also ther when the load is dominated by writes.
>
> I am teoprted to think that gstat is being screwy here, but it bothers me not
> knowing (especially as I am trying to tarck diwn bottlenecks in the system),
>
> Anyone got any opinions on what might be showing up here ?
To get a better idea of what is happening, you can run top -S to see
how much CPU the geli threads are using.
Also, how many eli volumes do you have? In my case, I have 13... In
order to reduce the load on the scheduler, I have:
kern.geom.eli.threads="1"
in /boot/loader.conf in order to prevent creating 6 threads (I have a
6 core CPU) per ELI device, or 78 threads in total...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
More information about the freebsd-geom
mailing list