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秒以內。