0

I have converted tables of a database from InnoDB to TokuDB and i noticed that with TokuDB, reads are using way too much CPU. Why is this?

To be more specific, the server with TokuDB tables is a slave of a server with InnoDB which is part of the PXC. The slave just used regular percona server and not PXC. But the slave seems to be using way too much CPU and i do not know why?

Below is my my.cnf config:

[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/

The following replication message was being reported by our monitoring system xymon when tokudb_cache_size when initially set to 80% of total RAM.

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.

------More info about the Master server running InnoDB and part of 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)
The Georgia
  • 1,005
  • 7
  • 23
  • 59

1 Answers1

0

Your CPU will be higher for reads because TokuDB data needs to be decompressed to be used. Also, if this slave is processing any activity from the master than it's also doing compression for the insert/update/delete activity.

Couple of ideas. 1. Reduce the value of tokudb_block_size. While 4MB is great for compression it means that your point queries need to decompress a lot more data than they have to. Try using 256KB and see how CPU and performance changes. You might have to rebuild your slave to accomplish this easily (I'm now over a year away from working at TokuDB). 2. Look at your tokudb_cache_size. It defaults to 50% of RAM, but if nothing else is on this server you should up it to somewhere between 75% and 80%. This will mean less reads and decompression since more data will be in your cache.

tmcallaghan
  • 1,292
  • 2
  • 10
  • 20
  • @mcallaghan, thanks for the response. My understanding of TokuDB is that data in cache is uncompressed, and that in disk is compressed. It is also my understanding that with TokuDB, it does not matter if the data size does not fit in RAM, as this will not degrade performance. So if we do have cached data (which contains uncompressed data), why would TokuDB need to decompress data? And tokudb_cache_size was initially set to 80% and we still had high CPU usage, plus some issue with replication. I have added the notification issued (check original post) when the slave had replication issues. – The Georgia Mar 03 '16 at 02:00
  • You are blending a lot of TokuDB concepts incorrectly. Bottom line, compression and decompression save IO at the expense of CPU, so CPU will always be higher with TokuDB. If you want to see it more apples-to-apples enable InnoDB compression on your master for your tables. To get more specific with help you need to explain your specific workload in much more detail. – tmcallaghan Mar 03 '16 at 15:59
  • I have provided more info about the master server in my original post. All tables on the master server are using InnoDB tables with compression = COMPRESSED. And all tables have charset='utf8mb4' and collate utf8mb4_general_ci. – The Georgia Mar 04 '16 at 02:20
  • Lets go back to the original quesion regarding CPU. How much is too much? Is using all available CPU on your server a bad thing? And lastly, why are you using TokuDB? – tmcallaghan Mar 05 '16 at 12:59
  • Yes, its using all the CPU and it is a bad thing and has impact on our Applications. We are using TokuDB as an experiment right now in hope to analyze its performance and decide if we might replace our InnoDB tables to TokuDB if performance proves better. For now, we are only using TokuDB on a slave for reads only. – The Georgia Mar 05 '16 at 15:02