MySQL写性能瓶颈

Question

我们正在尝试诊断 MySQL 瓶颈，特别是数据写入。基本上，我们有一个进程从文件夹中选取文件并使用LOAD DATA CONCURRENT INFILE. 目前看来，我们生成的文件比 MySQL 可以使用的要多。具体来说，我们每分钟生成大约一百万行（所有文件加起来），我们的摄取率为每秒 15,000 行（900,000 次写入）（基于Show Engine INNODB Status）。

表 X 有 31 列，其中 17 列是整数，12 个浮点数和 1 个字符 (10)，相当简单。它还有一个自动增量整数列和时间戳（纪元）和自动增量的主键。柱子。

MySQL 实例信息（物理主机）： 40 核，256 GB RAM，8 个 SSD 作为单个逻辑驱动器 (RAID 0) 我们同时使用 InnoDb 和 MYIASM，但我们试图优化写入的表驻留在 Innodb 中。

当前资源利用率： 10% CPU、50% 系统内存（已分配）、低磁盘利用率

MySQL Config: table_cache = 1000
thread_cache = 60
max_heap_table_size = 8192M
join_buffer_size = 256K
sort_buffer_size = 256K
query_cache_size = 512M
query_cache_limit = 512M
key_buffer_size = 8000M 
bulk_insert_buffer_size = 2000M
myisam_sort_buffer_size = 8000M
tmp_table_size = 8192M 
myisam_repair_threads  = 5
innodb_open_files = 10000
open_files_limit = 10000
concurrent_insert = 2

#innodb
innodb_flush_log_at_trx_commit = 2
innodb_support_xa = 0
innodb_buffer_pool_size = 128G
innodb_buffer_pool_instances =8
innodb_flush_method=O_DIRECT
innodb_log_file_size=1G
innodb_log_buffer_size=256M
innodb_thread_concurrency=8
innodb_file_per_table innodb_stats_on_metadata = 0
innodb_io_capacity=10000

我们打开了性能模式，以下是按总等待时间排序的罪魁祸首事件。第一组具有非 INNODB 事件，第二组用于 INNODB 事件。

mysql> SELECT EVENT_NAME, SUM_TIMER_WAIT FROM events_waits_summary_global_by_event_name where event_name not like '%innodb%' ORDER BY SUM_TIMER_WAIT DESC LIMIT 20;
+-------------------------------------------------------+-----------------+
| EVENT_NAME                                            | SUM_TIMER_WAIT  |
+-------------------------------------------------------+-----------------+
| wait/synch/cond/sql/MDL_context::COND_wait_status     | 247003180269200 |
| wait/synch/mutex/mysys/KEY_CACHE::cache_lock          | 225136157662400 |
| wait/io/file/myisam/dfile                             | 112586106594800 |
| wait/synch/cond/mysys/my_thread_var::suspend          | 36942967073600  |
| wait/io/file/sql/load                                 | 28575680068400  |
| wait/synch/mutex/sql/HA_DATA_PARTITION::LOCK_auto_inc | 15671510821200  |
| wait/synch/rwlock/myisam/MYISAM_SHARE::key_root_lock  | 7580580832000   |
| wait/io/file/sql/global_ddl_log                       | 759675521600    |
| wait/io/file/myisam/kfile                             | 478606412800    |
| wait/synch/mutex/sql/LOCK_open                        | 317343598000    |
| wait/io/file/sql/FRM                                  | 281702406000    |
| wait/synch/mutex/myisam/MYISAM_SHARE::intern_lock     | 237524998400    |
| wait/synch/mutex/mysys/THR_LOCK::mutex                | 148067737600    |
| wait/synch/cond/myisam/MI_SORT_INFO::cond             | 53355489600     |
| wait/synch/mutex/sql/TABLE_SHARE::LOCK_ha_data        | 40690076800     |
| wait/io/file/sql/slow_log                             | 32342937200     |
| wait/io/file/sql/partition                            | 32000921600     |
| wait/synch/cond/mysys/IO_CACHE_SHARE::cond            | 20865078800     |
| wait/synch/mutex/mysys/THR_LOCK_open                  | 18582940800     |
| wait/synch/mutex/sql/THD::LOCK_thd_data               | 15040836800     |
+-------------------------------------------------------+-----------------+




mysql> SELECT EVENT_NAME, SUM_TIMER_WAIT FROM events_waits_summary_global_by_event_name where event_name like '%innodb%' ORDER BY SUM_TIMER_WAIT DESC LIMIT 20;
+-----------------------------------------------+-----------------+
| EVENT_NAME                                    | SUM_TIMER_WAIT  |
+-----------------------------------------------+-----------------+
| wait/io/file/innodb/innodb_data_file          | 161894926356400 |
| wait/synch/mutex/innodb/log_sys_mutex         | 78901379729200  |
| wait/io/file/innodb/innodb_log_file           | 54154967108000  |
| wait/synch/mutex/innodb/log_flush_order_mutex | 31350108798800  |
| wait/synch/rwlock/innodb/btr_search_latch     | 29658726116800  |
| wait/synch/mutex/innodb/buf_pool_mutex        | 26124486124000  |
| wait/synch/mutex/innodb/kernel_mutex          | 9542359283600   |
| wait/synch/mutex/innodb/trx_undo_mutex        | 4636908475600   |
| wait/synch/mutex/innodb/autoinc_mutex         | 2176569546400   |
| wait/synch/mutex/innodb/fil_system_mutex      | 1580851583600   |
| wait/synch/mutex/innodb/dict_sys_mutex        | 764196921200    |
| wait/synch/mutex/innodb/flush_list_mutex      | 493146643200    |
| wait/synch/mutex/innodb/ibuf_mutex            | 415302790000    |
| wait/synch/rwlock/innodb/dict_table_stats     | 346864396800    |
| wait/synch/mutex/innodb/mutex_list_mutex      | 341627459200    |
| wait/synch/rwlock/innodb/checkpoint_lock      | 263200847600    |
| wait/synch/mutex/innodb/rw_lock_list_mutex    | 247598360000    |
| wait/synch/mutex/innodb/trx_doublewrite_mutex | 84526368000     |
| wait/synch/mutex/innodb/rseg_mutex            | 76199049600     |
| wait/synch/mutex/innodb/ibuf_bitmap_mutex     | 12117140800     |
+-----------------------------------------------+-----------------+

如果有人能指出我们正确的方向，我将不胜感激。

此外，我们一直在调整InnoDB的变量，例如innodb_concurrency_tickets，innodb_write_io_threads，innodb_flash_log_at_trx_commit等，但目前尚未观察到在性能上的重大转变。

Answer 1

第 1 步：关闭查询缓存。每次写入都会导致清除该表的 QC 中的所有条目！

query_cache_type = OFF
query_cache_size = 0

请提供SHOW CREATE TABLE。摆脱不必要的索引将提高INSERT性能，也许会显着提高。听起来你有

PRIMARY KEY(ts, id)
UNIQUE(id)

这样做会更有效率

PRIMARY KEY(ts, id)
INDEX(id)

是的，UNIQUE不需要（假设您没有AUTO_INCREMENT故意尝试插入重复 ID）。

所有的柱子都尽可能小吗？也就是说，当 SMALLINT UNSIGNED 可以工作时，您是否盲目地使用 INT？更小 --> 更少的 I/O --> 更快。（而且您似乎受 I/O 限制。）

如果您使用FusionIO，您可以安全地关闭双写缓冲区。

您是否考虑过使用多个连接“同时”插入多个数据集？

作为摄取的一部分，您是否对数据进行任何处理（例如标准化）？