Możliwości działania InnoDB INSERT

Cześć. Korzystam z najnowszej wersji Percona Server.

Wersja serwera: 5.5.24-55 Percona Server (GPL), wydanie 26.0

Mam 10 procesorów o tych cechach.

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

Ma dysk SSD i 64 GB pamięci RAM. Innodb ma około 10 GB, więc innodb_buffer_pool_size ustawiony na 10 GB.

Mam następującą tabelę:

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 )
)

Jeśli zacznę od pustej tabeli i wstawię 23 000 wierszy, zajmie to około 10 sekund. Jeśli następnie wykonam aktualizację, w której każda kolumna każdego wiersza jest aktualizowana (oprócz oczywiście symbol_id), zajmie to trochę więcej niż 11-12 sekund.

Czy ogólnie jest to wydajność zapisu, której powinienem oczekiwać od Innodb? Czy są jakieś sugestie dotyczące poprawy tej wydajności? aktualizacja 23 000 wierszy jest skrajnym przypadkiem, ponieważ zwykle w dniu handlu muszę aktualizować około 1000 wierszy co 5 sekund (więc jest to bardziej realistyczne ograniczenie, z którym mam do czynienia).

Inne istotne ustawienia mysql.cnf, które zmieniłem:

innodb_buffer_pool_size = 10G
innodb_log_file_size    = 64M
innodb_flush_log_at_trx_commit = 2
innodb_flush_method = O_DIRECT

BTW, jeśli zamiast Innodb utworzę tabelę z ENGINE = MEMORY, zajmuje około 4 sekund, aby wstawić, 6 sekund, aby wykonać aktualizację.

Wiele TIA, jeśli ktoś może mi pomóc dowiedzieć się, jaki jest punkt odniesienia dla tego typu zapytań lub pomóc mi poprawić czas.

Don

PS pełne ustawienia Innodb.

mysql> pokaż zmienne globalne, takie jak „innodb%”;
+ ------------------------------------------- + ----- ------------------- +
| Zmienna nazwa | Wartość |
+ ------------------------------------------- + ----- ------------------- +
| innodb_adaptive_flushing | ON |
| innodb_adaptive_flushing_method | oszacowanie |
| 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 | WYŁ
| 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 | wszystkie |
| innodb_checkpoint_age_target | 0 |
| innodb_checksums | ON |
| innodb_commit_concurrency | 0 |
| innodb_concurrency_tickets | 500 |
| innodb_corrupt_table Activity | twierdzić |
| 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 | WYŁ
| innodb_fast_checksum | WYŁ
| innodb_fast_shutdown | 1 |
| innodb_file_format | Antylopa |
| innodb_file_format_check | ON |
| innodb_file_format_max | Antylopa |
| innodb_file_per_table | WYŁ
| innodb_flush_log_at_trx_commit | 2 |
| innodb_flush_method | O_DIRECT |
| innodb_flush_neighbor_pages | obszar |
| innodb_force_load_corrupt | WYŁ
| 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 | WYŁ
| innodb_lazy_drop_table | 0 |
| innodb_lock_wait_timeout | 50 |
| innodb_locks_unsafe_for_binlog | WYŁ
| innodb_log_block_size | 512 |
| innodb_log_buffer_size | 8388608 |
| innodb_log_file_sile | 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 | WYŁ
| innodb_read_ahead | liniowy |
| innodb_read_ahead_threshold | 56 |
| innodb_read_io_threads | 4 |
| innodb_recovery_stats | WYŁ
| innodb_recovery_update_relay_log | WYŁ
| innodb_replication_delay | 0 |
| innodb_rollback_on_timeout | WYŁ
| 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 | WYŁ
| innodb_support_xa | ON |
| innodb_sync_spin_loops | 30 |
| innodb_table_locks | ON |
| innodb_thread_concurrency | 0 |
| innodb_thread_concurrency_timer_based | WYŁ
| 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 | WYŁ
| innodb_version | 1.1.8-rel26.0 |
| innodb_write_io_threads | 4 |
+ ------------------------------------------- + ----- ------------------- +
90 rzędów w zestawie (0,00 s)

Uruchomiłem numactl - hardware i oto wyjście, które otrzymałem. Komentarze mojego administratora są zanotowane poniżej (w odniesieniu do interpretacji).

root @ prog: / data / mysql # numactl --hardware
dostępne: 4 węzły (0-3)
węzeł 0 cpus: 0 1 2 3
rozmiar węzła 0: 32766 MB
węzeł 0 wolny: 21480 MB
węzeł 1 cpus: 4 5 6 7
rozmiar węzła 1: 32768 MB
węzeł 1 wolny: 25285 MB
węzeł 2 cpus: 12 13 14 15
rozmiar węzła 2: 32768 MB
węzeł 2 wolny: 20376 MB
węzeł 3 cpus: 8 9 10 11
rozmiar węzła 3: 32768 MB
węzeł 3 wolny: 24898 MB
odległości węzłów:
węzeł 0 1 2 3
  0: 10 16 16 16
  1: 16 10 16 16
  2: 16 16 10 16
  3: 16 16 16 10

Musisz dostroić ustawienia InnoDB w następujących obszarach:

• Uczyń InnoDB dostępem do wszystkich swoich rdzeni
• Zwiększ rozmiar innodb_buffer_pool_size do 12G
• Zwiększ innodb_buffer_pool_instances do 2 (Pierwsze uruchomienie w numactl --hardwarecelu ustalenia liczby procesorów fizycznych. Jaką liczbę zgłaszanych procesorów używaj, użyj tej liczby. Dowiedziałem się tego niedawno na blogu Jeremy'ego Cole'a )
• Zwiększ rozmiar pliku dziennika ( innodb_log_file_size ) do 2047M
• obsługa oddzielnych plików obszaru tabel dla poszczególnych tabel InnoDB (enaled innodb_file_per_table )
• obsługuje wysoką wydajność lub wysoką trwałość (zgodność z ACID)
  • Wysoka wydajność: innodb_flush_log_at_trx_commit ustawiony na 0 lub 2
  • Wysoka trwałość: innodb_flush_log_at_trx_commit ustawiony na 1 (domyślnie)
  • Zwiększ rozmiar innodb_log_buffer_size w połączeniu z liczbą transakcji na sekundę (być może 32M)
  • Twoje aktualne ustawienie dla innodb_flush_log_at_trx_commit jest dobre
  • Twoje obecne ustawienie dla innodb_flush_method jest dobre
• Zwiększ innodb_read_io_threads do 64
• Zwiększ innodb_write_io_threads do 64
• Zwiększ innodb_io_capactity do 10000

Oto moje poprzednie posty na temat dostrajania silnika pamięci InnoDB

• Czy wydajność procesora jest istotna dla serwera bazy danych? (26 kwietnia 2012 r.)
• Dlaczego InnoDB przechowuje wszystkie bazy danych w jednym pliku? (25 marca 2012 r.)
• Wiele rdzeni i wydajność MySQL (20 września 2011 r.)
• Czy można zmusić MySQL do korzystania z więcej niż jednego rdzenia? (12 września 2011 r.)
• Informacje o wydajności baz danych jednowątkowych i wielowątkowych (26 maja 2011 r.)
• Jak bezpiecznie zmienić zmienną innodb MySQL „innodb_log_file_size”? (16 lutego 2011 r.)
• Jak dostroić MySQL do dużego obciążenia InnoDB? (12 lutego 2011 r.)
• Howto: Wyczyść mysql silnik pamięci InnoDB? (29 października 2010 r.)