Можливості роботи InnoDB INSERT


11

Привіт, я запускаю останню версію 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 )
)

Якщо я розпочну з порожньої таблиці і вставлю 23000 рядків, це займе близько 10 секунд. Якщо згодом я оновлюю, де кожен стовпець кожного ряду оновлюється (за винятком символу_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

BTW, якщо замість Innodb я створю таблицю з ENGINE = ПАМ'ЯТЬ, для вставки потрібно близько 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 | OFF |
| innodb_buffer_pool_in вещества | 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 washing | стверджувати |
| innodb_data_file_path | ibdata1: 10M: autoextend |
| innodb_data_home_dir | |
| innodb_dict_size_limit | 0 |
| innodb_doublewrite | ON |
| innodb_doublewrite_file | |
| innodb_fake_changes | OFF |
| innodb_fast_checksum | OFF |
| innodb_fast_shutdown | 1 |
| innodb_file_format | Антилопа |
| innodb_file_format_check | ON |
| innodb_file_format_max | Антилопа |
| innodb_file_per_table | OFF |
| innodb_flush_log_at_trx_commit | 2 |
| innodb_flush_method | O_DIRECT |
| innodb_flush_neighbor_pages | площа |
| innodb_force_load_corrupted | OFF |
| 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 | OFF |
| innodb_lazy_drop_table | 0 |
| innodb_lock_wait_timeout | 50 |
| innodb_locks_unsafe_for_binlog | OFF |
| 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 | OFF |
| innodb_read_ahead | лінійний |
| innodb_read_ahead_threshold | 56 |
| innodb_read_io_threads | 4 |
| innodb_recovery_stats | OFF |
| innodb_recovery_update_relay_log | OFF |
| innodb_replication_delay | 0 |
| innodb_rollback_on_timeout | OFF |
| 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 | OFF |
| innodb_support_xa | ON |
| innodb_sync_spin_loops | 30 |
| innodb_table_locks | ON |
| innodb_thread_concurrency | 0 |
| innodb_thread_concurrency_timer_based | OFF |
| 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 | OFF |
| innodb_version | 1.1.8-відс.26.0 |
| innodb_write_io_threads | 4 |
+ ------------------------------------------- + ----- ------------------- +
90 рядків у наборі (0,00 сек)

Я запустив numactl --wareware і ось результат, який я отримав. Зауваження мого адміністратора вказані нижче (щодо тлумачення).

root @ prog: / data / mysql # numactl - програмне забезпечення
в наявності: 4 вузли (0-3)
вузол 0 cpus: 0 1 2 3
розмір вузла 0: 32766 Мб
вузол 0 безкоштовно: 21480 Мб
вузол 1 cpus: 4 5 6 7
розмір вузла 1: 32768 Мб
вузол 1 безкоштовно: 25285 Мб
вузол 2 cpus: 12 13 14 15
розмір вузла 2: 32768 Мб
вузол 2 безкоштовно: 20376 Мб
вузол 3 cpus: 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

Відповіді:


9

Потрібно налаштувати налаштування InnoDB у таких областях:

  • Зробіть доступ InnoDB до всіх ваших ядер
  • Збільшити розмір innodb_buffer_pool_size до 12G
  • Збільшити innodb_buffer_pool_in веществ до 2 (Перший запуск, numactl --hardwareщоб визначити кількість фізичних процесорів. Що кожне число процесорів, про які він повідомляє, використовуйте це число. Я дізнався про це нещодавно в блозі Джеремі Коула )
  • Збільшити розмір файлу журналу ( innodb_log_file_size ) до 2047 млн
  • підтримка окремих файлів просторових таблиць для окремих таблиць InnoDB (увімкнено 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


Thx за цю неймовірно корисну відповідь !! Я вітаю вас. Що стосується розміру журналу, чи повинен я турбуватися про те, щоб зробити його занадто великим? моя стурбованість - це те, що написав Ткаченко про mysqlperformanceblog.com/2011/09/18/disaster-mysql-5-5-flushing . Я усвідомлюю, що перебуваю на Перконі, тому, можливо, це не є проблемою .. але я хочу бути впевненим, що я не зіткнувся зі стійким сценарієм. Я переконуюсь у решті вашої відповіді ...
Дон Вул

з повагою innodb_buffer_pool_in вещества У мене є 16-процесорний ящик (я думав, що це 10). Що стосується numactl, мій адміністратор каже: "У вас 16 загальних процесорів і чотири блоки ОЗУ, 32G кожен. Кожен блок оперативної пам'яті розглядається як локальна пам'ять чотирма процесорами".
Дон Вул

Будь ласка, запустіть numactl --hardwareта опублікуйте вихідний запитання. Я намагаюся з'ясувати фізичні процесори і хочу переконатися, що адміністратор не говорить CPU, коли він має на увазі ядра.
RolandoMySQLDBA

Гаразд, я розмістив висновок "numactl" у питанні.
Дон Вул

Для мене висновок виглядає як чотирьохядерний ядро ​​(16 ядер) з використанням 4 процесорів. Тому встановлюйте innodb_buffer_pool_instances=4. Ще один запит: Перевірте, чи є у сервера БД 64 ГБ або 128 ГБ ???
RolandoMySQLDBA
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.