[MDEV-11738] Mariadb uses 100% of several of my 8 cpus doing nothing Created: 2017-01-07 Updated: 2020-12-17 Resolved: 2017-03-14 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | Encryption, Storage Engine - InnoDB, Storage Engine - XtraDB |
| Affects Version/s: | 10.1.20 |
| Fix Version/s: | 10.1.23 |
| Type: | Bug | Priority: | Major |
| Reporter: | Tim Passingham | Assignee: | Jan Lindström (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Environment: |
Linux 4.8.0-32-generic #34-Ubuntu SMP Tue Dec 13 14:30:43 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux Ubuntu 16.10 |
||
| Attachments: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Sprint: | 10.1.22 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
I use mariadb purely for a local sql database (via LibreOffice Base). There are no other users. Periodically the mysql process (still called that) take 37% (sometimes more) of the total available cpu, even though I am not doing anything at all, and the local database is not being used. If I restart the service the usage drops to 0%. I have not found any specific trigger for this behaviour. mysql.txt attached is the result of 'show engine innodb status;' |
| Comments |
| Comment by Elena Stepanova [ 2017-01-07 ] |
|
It is probably another case of That said, I'll still assign it to jplindst – given the number of complaints (which aren't altogether unfounded), maybe it makes sense to reconsider the design, at least for future releases? |
| Comment by Tim Passingham [ 2017-01-07 ] |
|
Thanks for this. I'll set the number of innodb-encrption-threads to 0. It still seems odd, given that I have no key rotation (as I understand it this plugin doesn't support it anyway), nor innodb-tablespaces-encryption on (so as I understand it only explicit tables and the log are encrypted). However, I am very much an amateur user, so I'm sure there was a purpose to all that activity. Apologies for raising an issue that had been raised before. I did search for issues but didn't know enough to realise where the problem might lie so didn't find the other reports. |
| Comment by Elena Stepanova [ 2017-01-07 ] |
|
pastim, in the attached config you do actually have innodb-encrypt-tables enabled. |
| Comment by Tim Passingham [ 2017-01-07 ] |
|
My understanding is that innodb-encrypt-tables has to be at least ON to allow me to encrypt some tables explicitly, which I want. I didn't want the overhead of using innodb-tablespaces-encryption, which I can imagine may require mariadb to do more work when not actually being used for queries. But as I said, I'm very much the amateur here |
| Comment by Jan Lindström (Inactive) [ 2017-02-02 ] |
|
bb-10.1- |
| Comment by Marko Mäkelä [ 2017-02-03 ] |
|
I would prefer to avoid adding a configuration parameter, and I think we should attach the collection of encrypted tablespaces directly to fil_system. |
| Comment by Jan Lindström (Inactive) [ 2017-02-14 ] |
|
https://github.com/MariaDB/server/commit/add67f3b5f37dedf53d770f6218d6c60cf409217 |
| Comment by Marko Mäkelä [ 2017-02-15 ] |
|
The patch is a step to the right direction, but I think that it needs some more refinement. I would remove the redundant flag fil_space_crypt_t::closing altogether and rely entirely on the fil_space_t fields stop_new_ops, n_pending_ops, and crypt_data with appropriate concurrency control. |
| Comment by Marko Mäkelä [ 2017-02-16 ] |
|
Please re-request a full review after addressing my review comments. |
| Comment by Jan Lindström (Inactive) [ 2017-02-21 ] |
|
https://github.com/mariadb/server/commit/bde1dad6a5021586a7ce899c611664ee82ec7697 |
| Comment by Marko Mäkelä [ 2017-02-27 ] |
|
I posted some review comments to GitHub. |
| Comment by Jan Lindström (Inactive) [ 2017-02-28 ] |
|
Tried to address most of the review comments, there were few that did not actually work. https://github.com/MariaDB/server/commit/352283b3ee08dc49880a729a8ed652d82acaa92c |
| Comment by Marko Mäkelä [ 2017-03-02 ] |
|
Thanks, it is getting better. I think that in order to move forward faster, it is OK to file follow-up bugs for some remaining issues. Remember to link them to this ticket. |
| Comment by Tim Passingham [ 2017-03-14 ] |
|
Do you need me, as one of the reporters and an 'ordinary' user, to test this? I assume that if I reset innodb-encryption-threads to, say, 4, I should be able to see that the problem doesn't re-occur. Let me know and I'll give a whirl. I just did an ubuntu update and mariadb is now 10.1.22, but that's not the latest as I understand it, so I'll need to find the latest one if you want me to test it. |
| Comment by Jan Lindström (Inactive) [ 2017-03-14 ] |
|
Please note that to disable key rotation you need to set innodb-encryption-rotate-key-age=0 |
| Comment by Marko Mäkelä [ 2017-03-14 ] |
|
pastim, this fix narrowly missed the 10.1.22 release, which was published today. |
| Comment by Tim Passingham [ 2017-03-14 ] |
|
I'll have to wait then I have set set innodb-encryption-rotate-key-age=0 |
| Comment by Jan Lindström (Inactive) [ 2017-03-14 ] |
|
commit 50eb40a2a8aa3af6cc271f6028f4d6d74301d030 Background: Key rotation is based on background threads This patch re-purposes innodb-encryption-rotate-key-age=0 fil0fil.cc: Added functions fil_space_acquire_low() fil_node_open_file(): After page 0 is read read also btr_scrub_lock_dict_func() buf_page_decrypt_after_read(): fil0crypt.cc/fil0fil.h: Lot of changes. Pass fil_space_t* directly fil_space_create(): Inform key rotation that there could fsp_header_init(): Acquire fil_space_t*, write crypt_data check_table_options() i_s.cc: Added ROTATING_OR_FLUSHING field to |