Capacidades de rendimiento de InnoDB INSERT

Hola, estoy ejecutando la versión más reciente de Percona Server.

Versión del servidor: 5.5.24-55 Servidor Percona (GPL), versión 26.0

Tengo una caja de 10 cpu de estas características.

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

Tiene SSD y 64GB de RAM. Innodb tiene aproximadamente 10 GB, por lo que innodb_buffer_pool_size está configurado en 10 GB.

Tengo una tabla que es la siguiente:

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

Si empiezo con una tabla vacía y hago una inserción de 23,000 filas, me toma alrededor de 10 segundos. Si posteriormente realizo una actualización donde se actualizan todas las columnas de cada fila (excepto symbol_id, por supuesto), tarda un poco más como 11-12 segundos.

¿Es esto genéricamente el rendimiento de escritura que debería esperar de Innodb? ¿Hay alguna sugerencia para mejorar este rendimiento? actualizar 23,000 filas es un caso extremo, ya que típicamente durante un día de negociación necesito actualizar aproximadamente 1000 filas cada 5 segundos (entonces, esa es la restricción más realista con la que estoy lidiando).

Otras configuraciones relevantes de mysql.cnf que he cambiado:

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

Por cierto, si en lugar de Innodb creo la tabla con ENGINE = MEMORY, se tarda unos 4 segundos en realizar la inserción, 6 segundos en realizar la actualización.

Muchos TIA si alguien me puede ayudar a descubrir cuál es el punto de referencia para este tipo de consulta, o ayudarme a mejorar el tiempo.

Don

Configuración completa de Innodb de PS.

mysql> muestra variables globales como 'innodb%';
+ ------------------------------------------- + ----- ------------------- +
El | Nombre_variable | Valor |
+ ------------------------------------------- + ----- ------------------- +
El | innodb_adaptive_flushing | ON |
El | innodb_adaptive_flushing_method | estimar |
El | innodb_adaptive_hash_index | ON |
El | innodb_adaptive_hash_index_partitions | 1 |
El | innodb_additional_mem_pool_size | 8388608 |
El | innodb_autoextend_increment | 8 |
El | innodb_autoinc_lock_mode | 1 |
El | innodb_blocking_buffer_pool_restore | OFF |
El | innodb_buffer_pool_instances | 1 |
El | innodb_buffer_pool_restore_at_startup | 0 |
El | innodb_buffer_pool_shm_checksum | ON |
El | innodb_buffer_pool_shm_key | 0 |
El | innodb_buffer_pool_size | 10737418240 |
El | innodb_change_buffering | todos |
El | innodb_checkpoint_age_target | 0 |
El | innodb_checksums | ON |
El | innodb_commit_concurrency | 0 |
El | innodb_concurrency_tickets | 500 |
El | innodb_corrupt_table_action | afirmar |
El | innodb_data_file_path | ibdata1: 10M: autoextend |
El | innodb_data_home_dir | El |
El | innodb_dict_size_limit | 0 |
El | innodb_doublewrite | ON |
El | innodb_doublewrite_file | El |
El | innodb_fake_changes | OFF |
El | innodb_fast_checksum | OFF |
El | innodb_fast_shutdown | 1 |
El | innodb_file_format | Antílope |
El | innodb_file_format_check | ON |
El | innodb_file_format_max | Antílope |
El | innodb_file_per_table | OFF |
El | innodb_flush_log_at_trx_commit | 2 |
El | innodb_flush_method | O_DIRECT |
El | innodb_flush_neighbor_pages | área |
El | innodb_force_load_corrupted | OFF |
El | innodb_force_recovery | 0 |
El | innodb_ibuf_accel_rate | 100
El | innodb_ibuf_active_contract | 1 |
El | innodb_ibuf_max_size | 5368692736 |
El | innodb_import_table_from_xtrabackup | 0 |
El | innodb_io_capacity | 200
El | innodb_kill_idle_transaction | 0 |
El | innodb_large_prefix | OFF |
El | innodb_lazy_drop_table | 0 |
El | innodb_lock_wait_timeout | 50
El | innodb_locks_unsafe_for_binlog | OFF |
El | innodb_log_block_size | 512
El | innodb_log_buffer_size | 8388608 |
El | innodb_log_file_size | 67108864 |
El | innodb_log_files_in_group | 2 |
El | innodb_log_group_home_dir | ./ |
El | innodb_max_dirty_pages_pct | 75 |
El | innodb_max_purge_lag | 0 |
El | innodb_mirrored_log_groups | 1 |
El | innodb_old_blocks_pct | 37 |
El | innodb_old_blocks_time | 0 |
El | innodb_open_files | 300
El | innodb_page_size | 16384 |
El | innodb_purge_batch_size | 20 |
El | innodb_purge_threads | 1 |
El | innodb_random_read_ahead | OFF |
El | innodb_read_ahead | lineal |
El | innodb_read_ahead_threshold | 56
El | innodb_read_io_threads | 4 |
El | innodb_recovery_stats | OFF |
El | innodb_recovery_update_relay_log | OFF |
El | innodb_replication_delay | 0 |
El | innodb_rollback_on_timeout | OFF |
El | innodb_rollback_segments | 128
El | innodb_show_locks_held | 10 |
El | innodb_show_verbose_locks | 0 |
El | innodb_spin_wait_delay | 6 |
El | innodb_stats_auto_update | 1 |
El | innodb_stats_method | nulls_equal |
El | innodb_stats_on_metadata | ON |
El | innodb_stats_sample_pages | 8 |
El | innodb_stats_update_need_lock | 1 |
El | innodb_strict_mode | OFF |
El | innodb_support_xa | ON |
El | innodb_sync_spin_loops | 30
El | innodb_table_locks | ON |
El | innodb_thread_concurrency | 0 |
El | innodb_thread_concurrency_timer_based | OFF |
El | innodb_thread_sleep_delay | 10000 |
El | innodb_use_global_flush_log_at_trx_commit | ON |
El | innodb_use_native_aio | ON |
El | innodb_use_sys_malloc | ON |
El | innodb_use_sys_stats_table | OFF |
El | innodb_version | 1.1.8-rel26.0 |
El | innodb_write_io_threads | 4 |
+ ------------------------------------------- + ----- ------------------- +
90 filas en conjunto (0.00 seg)

Ejecuté numactl --hardware y aquí está el resultado que obtuve. Los comentarios de mi administrador se indican a continuación (en cuanto a la interpretación).

root @ prog: / data / mysql # numactl - hardware
disponible: 4 nodos (0-3)
nodo 0 cpus: 0 1 2 3
tamaño de nodo 0: 32766 MB
nodo 0 libre: 21480 MB
nodo 1 cpus: 4 5 6 7
tamaño de nodo 1: 32768 MB
nodo 1 libre: 25285 MB
nodo 2 cpus: 12 13 14 15
tamaño de nodo 2: 32768 MB
nodo 2 libre: 20376 MB
nodo 3 cpus: 8 9 10 11
tamaño del nodo 3: 32768 MB
nodo 3 libre: 24898 MB
distancias de 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

Debe ajustar la configuración de InnoDB en las siguientes áreas:

• Haga que InnoDB acceda a todos sus núcleos
• Aumentar innodb_buffer_pool_size a 12G
• Aumente innodb_buffer_pool_instances a 2 (primera ejecución numactl --hardwarepara determinar el número de CPU físicas. Cada cantidad de CPU que informa, use ese número. Lo aprendí recientemente en el blog de Jeremy Cole )
• Aumente el tamaño del archivo de registro ( innodb_log_file_size ) a 2047M
• admite archivos de espacio de tabla separados para tablas InnoDB individuales ( innodb_file_per_table )
• admite alto rendimiento o alta durabilidad (cumplimiento de ACID)
  • Alto rendimiento: innodb_flush_log_at_trx_commit establecido en 0 o 2
  • Alta durabilidad: innodb_flush_log_at_trx_commit establecido en 1 (predeterminado)
  • Aumente el tamaño hasta innodb_log_buffer_size junto con el número de transacciones por segundo (quizás 32M)
  • Su configuración actual para innodb_flush_log_at_trx_commit es buena
  • Su configuración actual para innodb_flush_method es buena
• Aumentar innodb_read_io_threads a 64
• Aumentar innodb_write_io_threads a 64
• Aumentar innodb_io_capactity a 10000

Aquí están mis publicaciones anteriores sobre cómo ajustar el motor de almacenamiento InnoDB

• ¿El rendimiento de la CPU es relevante para un servidor de base de datos? (26 de abril de 2012)
• ¿Por qué InnoDB almacena todas las bases de datos en un archivo? (25 de marzo de 2012)
• Rendimiento de múltiples núcleos y MySQL (20 de septiembre de 2011)
• ¿Es posible hacer que MySQL use más de un núcleo? (12 de septiembre de 2011)
• Acerca del rendimiento de las bases de datos de subprocesos múltiples versus subprocesos múltiples (26 de mayo de 2011)
• ¿Cómo cambiar de forma segura la variable innodb de MySQL 'innodb_log_file_size'? (16 de febrero de 2011)
• ¿Cómo se ajusta MySQL para una gran carga de trabajo de InnoDB? (12 de febrero de 2011)
• Cómo: ¿Limpiar un motor de almacenamiento mysql InnoDB? (29 de octubre de 2010)