MySQL导入到Innodb表严重尖峰在某一点

Question

我试图从一台服务器迁移到另一台30GB的数据库。

简而言之，在整个过程的某个时间点，导入记录所花费的时间会随着时间的推移而严重增加。下面是使用source命令导入的500K记录的块（出约25-30〜百万整个数据库）导出为这是SSH的SQL文件隧道传送到新服务器：

... 

Query OK, 2871 rows affected (0.73 sec) 
Records: 2871 Duplicates: 0 Warnings: 0 

Query OK, 2870 rows affected (0.98 sec) 
Records: 2870 Duplicates: 0 Warnings: 0 

Query OK, 2865 rows affected (0.80 sec) 
Records: 2865 Duplicates: 0 Warnings: 0 

Query OK, 2871 rows affected (0.87 sec) 
Records: 2871 Duplicates: 0 Warnings: 0 

Query OK, 2864 rows affected (2.60 sec) 
Records: 2864 Duplicates: 0 Warnings: 0 

Query OK, 2866 rows affected (7.53 sec) 
Records: 2866 Duplicates: 0 Warnings: 0 

Query OK, 2879 rows affected (8.70 sec) 
Records: 2879 Duplicates: 0 Warnings: 0 

Query OK, 2864 rows affected (7.53 sec) 
Records: 2864 Duplicates: 0 Warnings: 0 

Query OK, 2873 rows affected (10.06 sec) 
Records: 2873 Duplicates: 0 Warnings: 0 

... 

峰值最终平均为每2800行受影响的16-18秒。当然，我通常不会将Source用于大型导入，但为了显示合法输出的清晰度，我使用它来了解什么时候会出现尖峰。使用mysql命令或mysqlimport会得到相同的结果。即使将结果直接输送到新数据库中，而不是通过一个sql文件产生这些尖峰。

据我所知，这发生在一定数量的记录被插入到表格后。我第一次启动一个服务器并导入一个大小的块，它会很好。给出或计算它处理的估计数量，直到出现这些尖峰。我无法把这个问题联系起来，因为我并没有一贯地将这个问题复制到显然的结论中。有20个表有500,000条记录，当这20个表通过一个命令导入时，所有导入的记录都很好。这似乎只发生在数据量过大的表上。当然，我到目前为止所解决的解决方案似乎只能解决随着时间的推移而出现的自然灾难（在我的情况下，期望的输出是最终导入500k记录的结果，这需要2-3秒每~2800，而似乎问题是在最后它不应该花那么长时间）。这来自一个名为“campaign_log”的sugarCRM表，其中有900万条记录。我能够以500k块的形式导入旧服务器，我正在迁移，而没有出现这些尖峰，所以我认为这与我的新服务器配置有关。另一件事是，每当发生这些尖峰时，它正在导入的表格似乎有一个尴尬的方式显示通过计数的记录＃。我知道InnoDB给出了估计数，但是这个数字并没有成功，表明估计。它通常是准确的，并且每次刷新表格时，它不会更改它显示的数量（这是基于它通过PHPMyAdmin报告的内容）

下面是关于新增的以下命令/ InnoDB系统变量服务器：

INNODB系统瓦尔：

+---------------------------------+------------------------+ 
| Variable_name     | Value     | 
+---------------------------------+------------------------+ 
| have_innodb      | YES     | 
| ignore_builtin_innodb   | OFF     | 
| innodb_adaptive_flushing  | ON      | 
| innodb_adaptive_hash_index  | ON      | 
| innodb_additional_mem_pool_size | 8388608    | 
| innodb_autoextend_increment  | 8      | 
| innodb_autoinc_lock_mode  | 1      | 
| innodb_buffer_pool_instances | 1      | 
| innodb_buffer_pool_size   | 8589934592    | 
| innodb_change_buffering   | all     | 
| innodb_checksums    | ON      | 
| innodb_commit_concurrency  | 0      | 
| innodb_concurrency_tickets  | 500     | 
| innodb_data_file_path   | ibdata1:10M:autoextend | 
| innodb_data_home_dir   |      | 
| innodb_doublewrite    | ON      | 
| 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 | 1      | 
| innodb_flush_method    | fsync     | 
| innodb_force_load_corrupted  | OFF     | 
| innodb_force_recovery   | 0      | 
| innodb_io_capacity    | 200     | 
| innodb_large_prefix    | OFF     | 
| innodb_lock_wait_timeout  | 50      | 
| innodb_locks_unsafe_for_binlog | OFF     | 
| innodb_log_buffer_size   | 8388608    | 
| innodb_log_file_size   | 5242880    | 
| 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_print_all_deadlocks  | OFF     | 
| innodb_purge_batch_size   | 20      | 
| innodb_purge_threads   | 1      | 
| innodb_random_read_ahead  | OFF     | 
| innodb_read_ahead_threshold  | 56      | 
| innodb_read_io_threads   | 8      | 
| innodb_replication_delay  | 0      | 
| innodb_rollback_on_timeout  | OFF     | 
| innodb_rollback_segments  | 128     | 
| innodb_spin_wait_delay   | 6      | 
| innodb_stats_method    | nulls_equal   | 
| innodb_stats_on_metadata  | ON      | 
| innodb_stats_sample_pages  | 8      | 
| innodb_strict_mode    | OFF     | 
| innodb_support_xa    | ON      | 
| innodb_sync_spin_loops   | 30      | 
| innodb_table_locks    | ON      | 
| innodb_thread_concurrency  | 0      | 
| innodb_thread_sleep_delay  | 10000     | 
| innodb_use_native_aio   | ON      | 
| innodb_use_sys_malloc   | ON      | 
| innodb_version     | 5.5.39     | 
| innodb_write_io_threads   | 8      | 
+---------------------------------+------------------------+ 

系统规格：

Intel Xeon E5-2680 v2 (Ivy Bridge) 8 Processors 
15GB Ram 
2x80 SSDs 

CMD导出：

mysqldump -u <olduser> <oldpw>, <olddb> <table> --verbose --disable-keys --opt | ssh -i <privatekey> <newserver> "cat > <nameoffile>" 

谢谢你的帮助。如果有任何其他信息可以提供，请告诉我。

Answer 1

我想通了。我将innodb_log_file_size从5MB增加到了1024MB。虽然它确实大大增加了我输入的记录数量（每3000行从未超过1秒），但它也修复了峰值。我输入的所有记录中只有2个，但在他们发生之后，他们立即回到1秒以内。