-
Notifications
You must be signed in to change notification settings - Fork 4.1k
Innodb: innodb_numa_interleave=1, use numa numa_get_mems_allowed #104
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Innodb: innodb_numa_interleave=1, use numa numa_get_mems_allowed #104
Conversation
Using numa_all_nodes_ptr was excessively optimistic. Due to constraints in systemd, containers or otherwise mysqld could of been limited to a smaller set of cpus. Use the numa_get_mems_allowed library function to see what we can interleave between before doing so. Signed-off-by: Daniel Black <[email protected]>
I confirm the code being submitted is offered under the terms of the OCA, and that I am authorized to contribute it. |
Hi, thank you for your contribution. Please confirm this code is submitted under the terms of the OCA (Oracle's Contribution Agreement) you have previously signed by cutting and pasting the following text as a comment: |
Hi, thank you for your contribution. Your code has been assigned to an internal queue. Please follow |
Summary: MyRocks did strict dictionary consistency check that newer index_id (passed by CREATE TABLE) must be larger than max_index_id stored in data dictionary. This is not always true. Suppose the following conditions. CREATE TABLE t1: 1) index_id= ddl_manager.get_next_number(); 4) dict_manager.update_max_index_id(batch, index_id) CREATE TABLE t2: 2) index_id= ddl_manager.get_next_number(); 3) dict_manager.update_max_index_id(batch, index_id) MyRocks returned an error on CREATE TABLE t1 because of dictionary condition check (dict_manager.update_max_index_id()). Then MyRocks crashed later by memory violation, because ddl_manager.put_and_write() was not cleaned up after failure. This diff fixes the issue by updating max_index_id in dictionary when getting new index id. This diff also renaming function name from ddl_manager.get_next_number() to ddl_manager.get_and_update_next_number(). Test Plan: mtr Reviewers: maykov, spetrunia, jkedgar, hermanlee4 Reviewed By: hermanlee4 Differential Revision: https://reviews.facebook.net/D45963
Summary: MyRocks did strict dictionary consistency check that newer index_id (passed by CREATE TABLE) must be larger than max_index_id stored in data dictionary. This is not always true. Suppose the following conditions. CREATE TABLE t1: 1) index_id= ddl_manager.get_next_number(); 4) dict_manager.update_max_index_id(batch, index_id) CREATE TABLE t2: 2) index_id= ddl_manager.get_next_number(); 3) dict_manager.update_max_index_id(batch, index_id) MyRocks returned an error on CREATE TABLE t1 because of dictionary condition check (dict_manager.update_max_index_id()). Then MyRocks crashed later by memory violation, because ddl_manager.put_and_write() was not cleaned up after failure. This diff fixes the issue by updating max_index_id in dictionary when getting new index id. This diff also renaming function name from ddl_manager.get_next_number() to ddl_manager.get_and_update_next_number(). Test Plan: mtr Reviewers: maykov, spetrunia, jkedgar, hermanlee4 Reviewed By: hermanlee4 Differential Revision: https://reviews.facebook.net/D45963
…ysql#104) Signed-off-by: Shlomi Noach <[email protected]>
…ysql#104) Signed-off-by: Shlomi Noach <[email protected]>
…ysql#104) Signed-off-by: Shlomi Noach <[email protected]>
* feat(rapid):performnace improvement in rapid to improve rapid performance. * mtr(rapid): add tests for rapid
Using numa_all_nodes_ptr was excessively optimistic. Due to
constraints in systemd, containers or otherwise MySQL could of been
limit to a smaller set of cpus. Use the numa_get_mems_allowed
library function to see what we can interleave between before doing
so.
Signed-off-by: Daniel Black [email protected]