MySQL TokuDB с использованием слишком большого количества CPU

Question

Я преобразовал таблицы базы данных из InnoDB в TokuDB, и я заметил, что с помощью TokuDB чтение использует слишком много CPU. Почему это?

Чтобы быть более конкретным, сервер с таблицами TokuDB является подчиненным сервером с InnoDB, который является частью PXC. Ведомый просто использовал обычный сервер percona, а не PXC. Но раб, похоже, использует слишком много процессора, и я не знаю почему?

Ниже мой my.cnf конфигурации:

[client] 
port   = 3306 
socket   = /var/run/mysqld/mysqld.sock 

[mysqld_safe] 
thp-setting=never 
socket   = /var/run/mysqld/mysqld.sock 
nice   = 0 
flush_caches 
numa_interleave 
core-file-size = unlimited 
open_files_limit = 1024 

[mysqld] 
back_log = 65535 
bind-address = 0.0.0.0 
binlog_format = ROW 
character_set_server = utf8 
collation_server = utf8_general_ci 
core_file 
basedir = /usr 
datadir = /var/lib/mysql 
#default_storage_engine = InnoDB 
enforce-gtid-consistency = 1 
expand_fast_index_creation = 1 
expire_logs_days = 7 
gtid_mode = ON 
innodb_autoinc_lock_mode = 2 
innodb_buffer_pool_instances = 1 
innodb_buffer_pool_populate = 1 
innodb_buffer_pool_size = 512M 
innodb_data_file_path = ibdata1:64M;ibdata2:64M:autoextend 
innodb_file_format = Barracuda 
innodb_file_per_table 
innodb_force_recovery = 1 
innodb_flush_log_at_trx_commit = 2 
innodb_flush_method = O_DIRECT 
innodb_io_capacity = 1600 
innodb_large_prefix 
innodb_locks_unsafe_for_binlog = 1 
innodb_log_file_size = 64M 
innodb_print_all_deadlocks = 1 
innodb_read_io_threads = 64 
innodb_stats_on_metadata = FALSE 
innodb_support_xa = FALSE 
innodb_write_io_threads = 64 
lc-messages-dir = /usr/share/mysql 
log-bin = mysqld-bin 
log-queries-not-using-indexes 
log-slave-updates 
long_query_time = 1 
master_info_repository = TABLE 
max_allowed_packet = 64M 
max_connect_errors = 4294967295 
max_connections = 2500 
max_user_connections = 2550 
min_examined_row_limit = 1000 
open_files_limit = 1024 
port = 3306 
relay_log_info_repository = TABLE 
relay-log-recovery = TRUE 
relay-log-recovery = 1 
skip-external-locking 
skip-name-resolve 
slave_parallel_workers = 8 
slow_query_log = 1 
slow_query_log_timestamp_always = 1 
socket = /var/run/mysqld/mysqld.sock 
table_open_cache = 4096 
thread_cache = 1024 
tmpdir = /srv/tmp 
transaction_isolation = REPEATABLE-READ 
updatable_views_with_limit = 0 
user = mysql 
wait_timeout = 60 

server-id = 2 
# TokuDB fine tuning 
default_storage_engine = TokuDB 
tokudb_analyze_time = 5 
#tokudb_cache_size = 6G 
tokudb_directio = 1 
tokudb_commit_sync = 0 
tokudb_fsync_log_period = 1000 
tokudb_load_save_space =1 
tokudb_alter_print_error=0 
tokudb_block_size = 4MB 
tokudb_bulk_fetch = 1 
tokudb_disable_slow_alter = 1 
tokudb_last_lock_timeout = empty 
tokudb_row_format = tokudb_quicklz 
#tokudb_data_dir = /var/lib/tokudb 


[mysqldump] 
quick 
quote-names 
max_allowed_packet  = 16M 

[mysql] 
#no-auto-rehash # faster start of mysql but no tab completition 

[isamchk] 
key_buffer    = 16M 
!includedir /etc/mysql/conf.d/ 

следующее сообщение репликация сообщается с помощью нашего мониторинга системы Xymon когда tokudb_cache_size когда первоначально установлен в 80% от общего объема оперативной памяти.

2016-02-25 16:42:04 9604 [Warning] Neither --relay-log nor --relay-log-index were used; so replication may break when this MySQL server acts as a slave and has his hostname changed!! Please use '--relay-log=db-kdb-slave-6-relay-bin' to avoid this problem. 
2016-02-25 16:42:05 9604 [Warning] Recovery from master pos 552554502 and file mysqld-bin.001163. Previous relay log pos and relay log file had been set to 552554714, ./db-kdb-slave-6-relay-bin.002933 respectively. 
2016-02-25 16:42:05 9604 [Warning] Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START SLAVE; see the 'START SLAVE Syntax' in the MySQL Manual for more information. 

------ Более подробная информация о мастер-сервере InnoDB и части PXC -----------

## Results from top 

top - 10:05:12 up 14 days, 7:56, 2 users, load average: 2.16, 2.31, 2.39 
Tasks: 413 total, 1 running, 412 sleeping, 0 stopped, 0 zombie 
%Cpu(s): 8.9 us, 0.6 sy, 0.0 ni, 89.9 id, 0.3 wa, 0.0 hi, 0.2 si, 0.0 st 
KiB Mem: 65704012 total, 63553216 used, 2150796 free, 169832 buffers 
KiB Swap: 975868 total, 809892 used, 165976 free. 16304268 cached Mem 

    PID USER  PR NI VIRT RES SHR S %CPU %MEM  TIME+ COMMAND 
2485 mysql  20 0 60.146g 0.045t 2.612g S 314.9 73.3 27762:43 mysqld 


## disk info 
george@db-erp-3:~$ df -h 
Filesystem  Size Used Avail Use% Mounted on 
udev    32G 8.0K 32G 1% /dev 
tmpfs   6.3G 1.2M 6.3G 1% /run 
/dev/sda2  274G 2.1G 258G 1%/
none    4.0K  0 4.0K 0% /sys/fs/cgroup 
none    5.0M  0 5.0M 0% /run/lock 
none    32G  0 32G 0% /run/shm 
none    100M  0 100M 0% /run/user 
/dev/nvme0n1p1 1.1T 542G 503G 52% /srv 
na1:/vol/yphome 4.5T 3.7T 875G 82% /net/account 

## Memory info 
george@db-erp-3:~$ free -g 
      total  used  free  shared buffers  cached 
Mem:   62   60   2   0   0   15 
-/+ buffers/cache:   44   17 
Swap:   0   0   0 
george@db-erp-3:~$ 


## Database info 
+--------------------+----------------------+ 
| Data Base Name  | Data Base Size in MB | 
+--------------------+----------------------+ 
| information_schema |   0.00976563 | 
| dberp    |  347143.32031250 | 
| mysql    |   2.11562061 | 
| performance_schema |   0.00000000 | 
+--------------------+----------------------+ 
4 rows in set (0.13 sec) 

+--------------------+----------------------+------------------+ 
| Data Base Name  | Data Base Size in MB | Free Space in MB | 
+--------------------+----------------------+------------------+ 
| information_schema |   0.00976563 |  0.00000000 | 
| dberp    |  347143.32031250 | 6270.00000000 | 
| mysql    |   2.11562061 |  4.00199127 | 
| performance_schema |   0.00000000 |  0.00000000 | 
+--------------------+----------------------+------------------+ 
4 rows in set (0.03 sec) 

Answer 1

Вашего процессор будет выше для чтения потому что данные TokuDB необходимо разжать, чтобы их можно было использовать. Кроме того, если это подчиненное устройство обрабатывает любую активность от мастера, а также выполняет сжатие для операции insert/update/delete.

Пара идей. 1. Уменьшите значение tokudb_block_size. В то время как 4 МБ отлично подходит для сжатия, это означает, что ваши точечные запросы должны декомпрессировать намного больше данных, чем нужно. Попробуйте использовать 256 КБ и посмотрите, как изменяется процессор и производительность. Возможно, вам придется перестроить своего раба, чтобы выполнить это легко (я уже более года от работы в TokuDB). 2. Посмотрите на свой файл tokudb_cache_size. По умолчанию он равен 50% ОЗУ, но если на этом сервере больше ничего нет, вы должны найти его где-то между 75% и 80%. Это будет означать меньше чтений и декомпрессии, поскольку в вашем кеше будет больше данных.