Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 27 Nov 2017 23:08:11 -0800
From:      John-Mark Gurney <jmg@funkthat.com>
To:        Pete French <petefrench@ingresso.co.uk>
Cc:        freebsd-geom@freebsd.org
Subject:   Re: GELI strangeness with gstat
Message-ID:  <20171128070811.GZ42467@funkthat.com>
In-Reply-To: <E1eJJ9M-000FSw-GZ@dilbert.ingresso.co.uk>
References:  <E1eJJ9M-000FSw-GZ@dilbert.ingresso.co.uk>

next in thread | previous in thread | raw e-mail | index | archive | help
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."



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171128070811.GZ42467>