Возможности InnoDB INSERT Performance

Привет я бегу самую последнюю версию Percona Server.

Версия сервера: 5.5.24-55 Percona Server (GPL), выпуск 26.0

У меня есть коробка с 10 процессорами этих характеристик.

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 и 64 ГБ оперативной памяти. Размер Innodb составляет около 10 ГБ, поэтому для innodb_buffer_pool_size установлено значение 10 ГБ.

У меня есть таблица, которая выглядит следующим образом:

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 строк - это крайний случай, так как обычно в течение торгового дня мне нужно обновлять около 1000 строк каждые 5 секунд (так что это более реалистичное ограничение, с которым я имею дело).

Другие соответствующие настройки 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> показать глобальные переменные вроде 'innodb%';
+ ------------------------------------------- + ----- ------------------- +
| Переменное_имя | Значение |
+ ------------------------------------------- + ----- ------------------- +
| innodb_adaptive_flushing | ON |
| innodb_adaptive_flushing_method | оценить |
| 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 | ВЫКЛ |
| 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 | все |
| innodb_checkpoint_age_target | 0 |
| innodb_checksums | ON |
| innodb_commit_concurrency | 0 |
| innodb_concurrency_tickets | 500 |
| innodb_corrupt_table_action | утверждать |
| innodb_data_file_path | ibdata1: 10M: автоматическое расширение |
| innodb_data_home_dir | |
| innodb_dict_size_limit | 0 |
| innodb_doublewrite | ON |
| innodb_doublewrite_file | |
| innodb_fake_changes | ВЫКЛ |
| innodb_fast_checksum | ВЫКЛ |
| innodb_fast_shutdown | 1 |
| innodb_file_format | Антилопа |
| innodb_file_format_check | ON |
| innodb_file_format_max | Антилопа |
| innodb_file_per_table | ВЫКЛ |
| innodb_flush_log_at_trx_commit | 2 |
| innodb_flush_method | O_DIRECT |
| innodb_flush_neighbor_pages | площадь |
| innodb_force_load_corrupted | ВЫКЛ |
| 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 | ВЫКЛ |
| innodb_lazy_drop_table | 0 |
| innodb_lock_wait_timeout | 50 |
| innodb_locks_unsafe_for_binlog | ВЫКЛ |
| 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 | ВЫКЛ |
| innodb_read_ahead | линейный |
| innodb_read_ahead_threshold | 56 |
| innodb_read_io_threads | 4 |
| innodb_recovery_stats | ВЫКЛ |
| innodb_recovery_update_relay_log | ВЫКЛ |
| innodb_replication_delay | 0 |
| innodb_rollback_on_timeout | ВЫКЛ |
| 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 | ВЫКЛ |
| innodb_support_xa | ON |
| innodb_sync_spin_loops | 30 |
| innodb_table_locks | ON |
| innodb_thread_concurrency | 0 |
| innodb_thread_concurrency_timer_based | ВЫКЛ |
| 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 | ВЫКЛ |
| innodb_version | 1.1.8-rel26.0 |
| innodb_write_io_threads | 4 |
+ ------------------------------------------- + ----- ------------------- +
90 рядов в наборе (0,00 сек)

Я запустил numactl --hardware и вот результат, который я получил. Комментарии от моего администратора отмечены ниже (что касается интерпретации).

root @ prog: / data / mysql # numactl - аппаратное обеспечение
доступно: 4 узла (0-3)
узел 0 процессор: 0 1 2 3
размер узла 0: 32766 МБ
свободный узел 0: 21480 МБ
узел 1 процессор: 4 5 6 7
размер узла 1: 32768 МБ
свободный узел 1: 25285 МБ
узел 2 процессор: 12 13 14 15
размер узла 2: 32768 МБ
свободный узел 2: 20376 МБ
узел 3 процессор: 8 9 10 11
размер узла 3: 32768 МБ
свободный узел 3: 24898 МБ
расстояния до узла:
узел 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 --hardwareчтобы определить количество физических процессоров. Для каждого числа процессоров, которые он сообщает, используйте это число. Я узнал об этом недавно в блоге Джереми Коула )
• Увеличьте размер файла журнала ( innodb_log_file_size ) до 2047M
• поддержка отдельных файлов табличного пространства для отдельных таблиц InnoDB (enaled innodb_file_per_table )
• поддерживать высокую производительность или долговечность (соответствие ACID)
  • Высокая производительность: innodb_flush_log_at_trx_commit установлен в 0 или 2
  • Высокая долговечность: innodb_flush_log_at_trx_commit установлен в 1 (по умолчанию)
  • Увеличить Размер до innodb_log_buffer_size в сочетании с количеством транзакций в секунду (возможно, 32 МБ).
  • Ваш текущий параметр для innodb_flush_log_at_trx_commit хорош
  • Ваш текущий параметр для innodb_flush_method хорош
• Увеличьте innodb_read_io_threads до 64
• Увеличьте innodb_write_io_threads до 64
• Увеличьте innodb_io_capactity до 10000

Вот мои прошлые сообщения о настройке механизма хранения InnoDB

• Соответствует ли производительность процессора серверу баз данных? (26 апреля 2012 г.)
• Почему InnoDB хранит все базы данных в одном файле? (25 марта 2012 г.)
• Многоядерность и производительность MySQL (20 сентября 2011 г.)
• Можно ли заставить MySQL использовать более одного ядра? (12 сентября 2011 г.)
• О производительности однопоточных и многопоточных баз данных (26 мая 2011 г.)
• Как безопасно изменить переменную MySQL innodb 'innodb_log_file_size'? (16 февраля 2011 г.)
• Как вы настраиваете MySQL для тяжелой рабочей нагрузки InnoDB? (12 февраля 2011 г.)
• Как: Очистить движок хранения MySQL InnoDB? (29 октября 2010 г.)