mysql – InnoDB INSERT性能的功能
作者：互联网
嗨,我正在运行最新版本的Percona Server.
服务器版本：5.5.24-55 Percona Server(GPL),版本26.0
我有一个具有这些特征的10个CPU盒.
processor : 0
vendor_id : AuthenticAMD
cpu family : 16
model : 9
model name : AMD Opteron(tm) Processor 6128
stepping : 1
microcode : 0x10000d9
cpu MHz : 800.000
cache size : 512 KB
它有SSD和64GB的RAM. Innodb约为10GB,因此innodb_buffer_pool_size设置为10GB.
我有一张表如下：
create table TODAY
( symbol_id integer not null
, openp decimal(10,4)
, high decimal(10,4)
, low decimal(10,4)
, last decimal(10,4) not null
, volume int
, last_updated datetime -- the time of the last quote update
, prev decimal(10,4) null
, PRIMARY KEY ( symbol_id )
)
如果我从空表开始并插入23,000行,则需要大约10秒钟.如果我随后进行更新,其中每行的每一列都更新(当然除了symbol_id),它需要11-12秒.
这通常是Innodb应该期待的写性能吗？有没有改善这种表现的建议？更新23,000行是一种极端情况,因为通常在交易日我需要每5秒更新大约1000行(因此,这是我正在处理的更现实的约束).
我改变了其他相关的mysql.cnf设置：
innodb_buffer_pool_size = 10G
innodb_log_file_size = 64M
innodb_flush_log_at_trx_commit = 2
innodb_flush_method = O_DIRECT
顺便说一句,如果不是Innodb,我用ENGINE = MEMORY创建表,它需要大约4秒来完成插入,6秒钟来进行更新.
许多TIA,如果有人可以帮我弄清楚这种类型的查询的基准是什么,或者帮助我改善时间.
唐
PS全套Innodb设置.
mysql> show global variables like 'innodb%'; +-------------------------------------------+------------------------+ | Variable_name | Value | +-------------------------------------------+------------------------+ | innodb_adaptive_flushing | ON | | innodb_adaptive_flushing_method | estimate | | innodb_adaptive_hash_index | ON | | innodb_adaptive_hash_index_partitions | 1 | | innodb_additional_mem_pool_size | 8388608 | | innodb_autoextend_increment | 8 | | innodb_autoinc_lock_mode | 1 | | innodb_blocking_buffer_pool_restore | OFF | | innodb_buffer_pool_instances | 1 | | innodb_buffer_pool_restore_at_startup | 0 | | innodb_buffer_pool_shm_checksum | ON | | innodb_buffer_pool_shm_key | 0 | | innodb_buffer_pool_size | 10737418240 | | innodb_change_buffering | all | | innodb_checkpoint_age_target | 0 | | innodb_checksums | ON | | innodb_commit_concurrency | 0 | | innodb_concurrency_tickets | 500 | | innodb_corrupt_table_action | assert | | innodb_data_file_path | ibdata1:10M:autoextend | | innodb_data_home_dir | | | innodb_dict_size_limit | 0 | | innodb_doublewrite | ON | | innodb_doublewrite_file | | | innodb_fake_changes | OFF | | innodb_fast_checksum | OFF | | innodb_fast_shutdown | 1 | | innodb_file_format | Antelope | | innodb_file_format_check | ON | | innodb_file_format_max | Antelope | | innodb_file_per_table | OFF | | innodb_flush_log_at_trx_commit | 2 | | innodb_flush_method | O_DIRECT | | innodb_flush_neighbor_pages | area | | innodb_force_load_corrupted | OFF | | innodb_force_recovery | 0 | | innodb_ibuf_accel_rate | 100 | | innodb_ibuf_active_contract | 1 | | innodb_ibuf_max_size | 5368692736 | | innodb_import_table_from_xtrabackup | 0 | | innodb_io_capacity | 200 | | innodb_kill_idle_transaction | 0 | | innodb_large_prefix | OFF | | innodb_lazy_drop_table | 0 | | innodb_lock_wait_timeout | 50 | | innodb_locks_unsafe_for_binlog | OFF | | innodb_log_block_size | 512 | | innodb_log_buffer_size | 8388608 | | innodb_log_file_size | 67108864 | | innodb_log_files_in_group | 2 | | innodb_log_group_home_dir | ./ | | innodb_max_dirty_pages_pct | 75 | | innodb_max_purge_lag | 0 | | innodb_mirrored_log_groups | 1 | | innodb_old_blocks_pct | 37 | | innodb_old_blocks_time | 0 | | innodb_open_files | 300 | | innodb_page_size | 16384 | | innodb_purge_batch_size | 20 | | innodb_purge_threads | 1 | | innodb_random_read_ahead | OFF | | innodb_read_ahead | linear | | innodb_read_ahead_threshold | 56 | | innodb_read_io_threads | 4 | | innodb_recovery_stats | OFF | | innodb_recovery_update_relay_log | OFF | | innodb_replication_delay | 0 | | innodb_rollback_on_timeout | OFF | | innodb_rollback_segments | 128 | | innodb_show_locks_held | 10 | | innodb_show_verbose_locks | 0 | | innodb_spin_wait_delay | 6 | | innodb_stats_auto_update | 1 | | innodb_stats_method | nulls_equal | | innodb_stats_on_metadata | ON | | innodb_stats_sample_pages | 8 | | innodb_stats_update_need_lock | 1 | | innodb_strict_mode | OFF | | innodb_support_xa | ON | | innodb_sync_spin_loops | 30 | | innodb_table_locks | ON | | innodb_thread_concurrency | 0 | | innodb_thread_concurrency_timer_based | OFF | | innodb_thread_sleep_delay | 10000 | | innodb_use_global_flush_log_at_trx_commit | ON | | innodb_use_native_aio | ON | | innodb_use_sys_malloc | ON | | innodb_use_sys_stats_table | OFF | | innodb_version | 1.1.8-rel26.0 | | innodb_write_io_threads | 4 | +-------------------------------------------+------------------------+ 90 rows in set (0.00 sec)
我运行numactl – 硬件,这是我得到的输出.我的管理员的评论如下(如解释).
root@prog:/data/mysql# numactl --hardware available: 4 nodes (0-3) node 0 cpus: 0 1 2 3 node 0 size: 32766 MB node 0 free: 21480 MB node 1 cpus: 4 5 6 7 node 1 size: 32768 MB node 1 free: 25285 MB node 2 cpus: 12 13 14 15 node 2 size: 32768 MB node 2 free: 20376 MB node 3 cpus: 8 9 10 11 node 3 size: 32768 MB node 3 free: 24898 MB node distances: node 0 1 2 3 0: 10 16 16 16 1: 16 10 16 16 2: 16 16 10 16 3: 16 16 16 10
解决方法:
您需要在以下区域调整InnoDB设置：
>让InnoDB访问您的所有核心
>将innodb_buffer_pool_size增加到12G
>将innodb_buffer_pool_instances增加到2(首先运行numactl – 硬件以确定物理CPU的数量.它报告的每个CPU数量,使用该数量.我最近在Jeremy Cole’s Blog学到了这一点)
>将日志文件大小(innodb_log_file_size)增加到2047M
>支持单个InnoDB表的单独表空间文件(已启用innodb_file_per_table)
>支持高性能或高耐用性(ACID合规性)
>高性能：innodb_flush_log_at_trx_commit设置为0或2
>高耐久性：innodb_flush_log_at_trx_commit设置为1(默认)
>增加innodb_log_buffer_size的尺寸以及每秒的交易数量(可能是32M)
> innodb_flush_log_at_trx_commit的当前设置很好
>您对innodb_flush_method的当前设置很好
>将innodb_read_io_threads增加到64
>将innodb_write_io_threads增加到64
>将innodb_io_capactity增加到10000
以下是我过去关于调整InnoDB存储引擎的帖子
> Is the CPU performance relevant for a database server?(2012年4月26日)
> Why does InnoDB store all databases in one file?(2012年3月25日)
> Multi cores and MySQL Performance(2011年9月20日)
> Possible to make MySQL use more than one core?(2011年9月12日)
> About single threaded versus multithreaded databases performance(2011年5月26日)
> How to safely change MySQL innodb variable ‘innodb_log_file_size’?(2011年2月16日)
> How do you tune MySQL for a heavy InnoDB workload?(2011年2月12日)
> Howto: Clean a mysql InnoDB storage engine?(2010年10月29日)
标签：performance,mysql,innodb,percona-server 来源： https://codeday.me/bug/20190805/1589233.html