High CPU usage when TDE is enabled

Hello everyone,

I've ran into an issue when applying TDE on my MariaDB instance. The procedure that I've used is this one here: https://mariadb.com/resources/blog/mariadb-encryption-tde-using-mariadbs-file-key-management-encryption-plugin/

Once I make the changes in the my.cnf file and restart the service, the encryption will start applying to the tables, and once it applied to all the tables the CPU usage would jump from about 5-10% to 75-80%. This really makes no sense to me, is this a known bug or something?

From what I've read in this article: https://mariadb.com/kb/en/data-at-rest-encryption-overview/#:%7E:text=MariaDB%20got%20Data%2Dat%2DRest,of%20roughly%203%2D5%25

MariaDB got Data-at-Rest Encryption with MariaDB 10.1. This functionality is also known as "Transparent Data Encryption (TDE)". This assumes that encryption keys are stored on another system. Using encryption has an overhead of roughly 3-5%.

This is no even close to being true, at least in my case.

The only solution that I've found is lowering the value for innodb_encryption_threads from the suggest 4 to 1. Another setting that might be innodb_encryption_rotation_iops the mentioned value in the procedure is 2000 (but no explanation on what are some recommended settings).

This VM has 4 CPUs and 16GB of RAM, and it will be used for ServiceNow.

EDIT: Additional information has been added.

Server is running Red Hat Enterprise Linux 8.5 (Ootpa) MariaDB Community Edition Version 10.3.34

Setting innodb_encryption_rotate_key_age variable to 0 did not have any impact in reducing the CPU usage. Lowering the innodb_encryption_rotation_iops from 2000 to 1000 also didn't seem to have an impact.

InnoDB Buffer usage has been added, it's at 7% so that should be fine.

I'm attaching the my.cnf file which I'm using. I'm returned the innodb_encryption_threads back to 4, innodb_encryption_rotation_iops are 1000 and innodb_encryption_rotate_key_age is 0.

Any help would be greatly appreciated.

Comments

Comments loading...
Content reproduced on this site is the property of its respective owners, and this content is not reviewed in advance by MariaDB. The views, information and opinions expressed by this content do not necessarily represent those of MariaDB or any other party.