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 KBMa 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_DIRECTBTW, 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