Funzionalità di InnoDB INSERT Performance

Ciao, sto eseguendo la versione più recente di Percona Server.

Versione server: 5.5.24-55 Percona Server (GPL), versione 26.0

Ho una confezione da 10 cpu con queste caratteristiche.

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

Ha SSD e 64 GB di RAM. Innodb è di circa 10 GB, quindi innodb_buffer_pool_size impostato su 10 GB.

Ho una tabella che è la seguente:

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

Se inizio con una tabella vuota e faccio un inserimento di 23.000 righe, ci vogliono circa 10 secondi. Se successivamente eseguo un aggiornamento in cui viene aggiornata ogni colonna di ogni riga (ad eccezione di symbol_id ovviamente) ci vogliono un po 'più di 11-12 secondi.

Questa è generalmente la performance di scrittura che dovrei aspettarmi da Innodb? C'è qualche suggerimento per migliorare questa prestazione? l'aggiornamento di 23.000 righe è un caso estremo, come in genere durante una giornata di trading ho bisogno di aggiornare circa 1000 righe ogni 5 secondi (quindi, questo è il vincolo più realistico che sto affrontando).

Altre impostazioni pertinenti di mysql.cnf che ho modificato:

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

A proposito se invece di Innodb creo la tabella con ENGINE = MEMORY ci vogliono circa 4 secondi per fare l'inserimento, 6 secondi per fare l'aggiornamento.

Molti TIA se qualcuno può aiutarmi a capire qual è il punto di riferimento per questo tipo di query, o aiutarmi a migliorare il tempo.

don

PS impostazioni complete Innodb.

mysql> mostra variabili globali come 'innodb%';
+ ------------------------------------------- + ----- ------------------- +
| Nome variabile | Valore |
+ ------------------------------------------- + ----- ------------------- +
| innodb_adaptive_flushing | ON |
| innodb_adaptive_flushing_method | stima |
| 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_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 | tutto |
| innodb_checkpoint_age_target | 0 |
| innodb_checksums | ON |
| innodb_commit_concurrency | 0 |
| innodb_concurrency_tickets | 500 |
| innodb_corrupt_table_action | affermare |
| 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 | Antilope |
| innodb_file_format_check | ON |
| innodb_file_format_max | Antilope |
| innodb_file_per_table | OFF |
| innodb_flush_log_at_trx_commit | 2 |
| innodb_flush_method | O_DIRECT |
| innodb_flush_neighbor_pages | area |
| 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 | lineare |
| 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-rel26.0 |
| innodb_write_io_threads | 4 |
+ ------------------------------------------- + ----- ------------------- +
90 righe in set (0,00 sec)

Ho eseguito numactl --hardware ed ecco l'output che ho ottenuto. I commenti del mio amministratore sono riportati di seguito (come per l'interpretazione).

root @ prog: / data / mysql # numactl --hardware
disponibile: 4 nodi (0-3)
nodo 0 cpus: 0 1 2 3
dimensione nodo 0: 32766 MB
nodo 0 libero: 21480 MB
nodo 1 cpus: 4 5 6 7
dimensione nodo 1: 32768 MB
nodo 1 libero: 25285 MB
nodo 2 cpus: 12 13 14 15
dimensione nodo 2: 32768 MB
nodo 2 libero: 20376 MB
nodo 3 cpus: 8 9 10 11
dimensione nodo 3: 32768 MB
nodo 3 libero: 24898 MB
distanze nodo:
nodo 0 1 2 3
  0: 10 16 16 16
  1: 16 10 16 16
  2: 16 16 10 16
  3: 16 16 16 10

È necessario ottimizzare le impostazioni di InnoDB nelle seguenti aree:

• Rendi InnoDB accesso a tutti i tuoi core
• Aumenta innodb_buffer_pool_size a 12G
• Aumenta innodb_buffer_pool_instances a 2 (Prima esecuzione numactl --hardwareper determinare il numero di CPU fisiche. Ciò che ogni numero di CPU riporta, usa quel numero. L'ho imparato recentemente nel Blog di Jeremy Cole )
• Aumenta la dimensione del file di registro ( innodb_log_file_size ) a 2047M
• supporta file tablespace separati per singole tabelle InnoDB (enaled innodb_file_per_table )
• supporta prestazioni elevate o lunga durata (conformità ACID)
  • Alte prestazioni: innodb_flush_log_at_trx_commit impostato su 0 o 2
  • Alta durata: innodb_flush_log_at_trx_commit impostato su 1 (impostazione predefinita)
  • Aumenta dimensioni fino a innodb_log_buffer_size insieme al numero di transazioni al secondo (forse 32 M)
  • L'impostazione corrente per innodb_flush_log_at_trx_commit è buona
  • L'impostazione corrente per innodb_flush_method è buona
• Aumenta innodb_read_io_threads a 64
• Aumenta innodb_write_io_threads a 64
• Aumenta innodb_io_capactity a 10000

Ecco i miei post precedenti sulla messa a punto del motore di archiviazione InnoDB

• Le prestazioni della CPU sono rilevanti per un server di database? (26 aprile 2012)
• Perché InnoDB memorizza tutti i database in un unico file? (25 marzo 2012)
• Multi core e prestazioni MySQL (20 settembre 2011)
• È possibile fare in modo che MySQL utilizzi più di un core? (12 settembre 2011)
• Informazioni sulle prestazioni dei database a thread singolo o multithread (26 maggio 2011)
• Come modificare in modo sicuro la variabile innodb di MySQL 'innodb_log_file_size'? (16 febbraio 2011)
• Come si sintonizza MySQL per un carico di lavoro pesante di InnoDB? (12 febbraio 2011)
• Come: pulire un motore di archiviazione mysql InnoDB? (29 ottobre 2010)