Я недавно перенес базу данных с физического сервера MySQL 5.6 на Percona 5.7 Centos 7 VM. В устаревшей среде загрузка файла CSV 27G в одну таблицу заняла 2 часа. В новой среде с сильно модернизированными ресурсами (ОЗУ, ЦП и т. Д. c) он будет работать более 24 часов и никогда не завершится.
Подробности: ЦП сервера для процесса mysqld увеличится до 100 %, когда задание запускается и поддерживается, пока процесс не будет уничтожен в БД или командной строке. Это таблица MyISAM. (Я не хочу слышать о InnoDB. Этот механизм является требованием клиента, и его не нужно менять). В течение 10 секунд файл MYI для таблицы будет иметь размер 451 МБ и остановится. Через 5 минут он увеличивается до 939 МБ в течение 5-10 секунд и снова останавливается. Через час или два он снова увеличится до 1.6G. 24 часа спустя он может достигать 6,2 г; но не превышает эту точку.
Напомним, что в «тихие» времена процессор находится на уровне 100 +%. IO равен нулю, за исключением тех нескольких секунд, когда он записывает в файл MYI. Загрузка сервера 1-2. Использование памяти не более 27%. Диск SSD. Сервер имеет 96 ГБ ОЗУ.
Таблица обрезается перед каждым запуском сценария, поэтому не используется. Ключи автоматически отключаются из-за пустой таблицы. Я попытался настроить каждый буфер, и ничто не меняет результаты в любом случае. Я изменил таблицу на InnoDB, без разницы, за исключением того, что файлы немного больше; но точки остановки одинаковы и не заканчиваются sh.
Я смотрел на буферы уровня ОС и кэширование и тоже ничего не нашел.
Идеи?
mysql> show global variables like '%buffer%';
+-------------------------------------+----------------+
| Variable_name | Value |
+-------------------------------------+----------------+
| audit_log_buffer_size | 1048576 |
| bulk_insert_buffer_size | 67108864 |
| innodb_buffer_pool_chunk_size | 134217728 |
| innodb_buffer_pool_dump_at_shutdown | ON |
| innodb_buffer_pool_dump_now | OFF |
| innodb_buffer_pool_dump_pct | 25 |
| innodb_buffer_pool_filename | ib_buffer_pool |
| innodb_buffer_pool_instances | 8 |
| innodb_buffer_pool_load_abort | OFF |
| innodb_buffer_pool_load_at_startup | ON |
| innodb_buffer_pool_load_now | OFF |
| innodb_buffer_pool_size | 10737418240 |
| innodb_change_buffer_max_size | 25 |
| innodb_change_buffering | all |
| innodb_log_buffer_size | 134217728 |
| innodb_sort_buffer_size | 1048576 |
| join_buffer_size | 8388608 |
| key_buffer_size | 26843545600 |
| myisam_sort_buffer_size | 4294967296 |
| net_buffer_length | 16384 |
| preload_buffer_size | 32768 |
| read_buffer_size | 1048576 |
| read_rnd_buffer_size | 10485760 |
| sort_buffer_size | 67108864
Ядра сервера: 8 процессоров с 8 ядрами в каждом
set sql_log_bin = 0;
LOCK TABLES t_surescripts_full WRITE;
TRUNCATE TABLE t_surescripts_full;
LOAD DATA LOCAL INFILE '/data/0149561_SS_PRE/SS_PRE_20200108_v44.match_output.just_output_records' INTO TABLE t_surescripts_full CHARACTER SET 'latin1'
FIELDS TERMINATED BY '|' OPTIONALLY ENCLOSED BY '"' ESCAPED BY ''
LINES TERMINATED BY '\n';
UNLOCK TABLES;
Список процессов не очень полезен, поскольку загрузка данных с данными является единственным запросом, а его состояние «выполняется» даже через 20 часов. .
ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 385429
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 10240
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 10240
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited