Capacités des performances InnoDB INSERT

Salut, je lance la version la plus récente de Percona Server.

Version du serveur: 5.5.24-55 Percona Server (GPL), Release 26.0

J'ai une boîte de 10 cpu de ces caractéristiques.

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

Il a un SSD et 64 Go de RAM. Innodb fait environ 10 Go, donc innodb_buffer_pool_size défini sur 10 Go.

J'ai un tableau qui se présente comme suit:

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 je commence avec une table vide et que j'insère 23 000 lignes, cela prend environ 10 secondes. Si je fais ensuite une mise à jour où chaque colonne de chaque ligne est mise à jour (sauf symbol_id bien sûr), cela prend un peu plus de 11 à 12 secondes.

Est-ce génériquement la performance d'écriture que je devrais attendre d'Innodb? Y a-t-il une suggestion pour améliorer ces performances? la mise à jour de 23 000 lignes est un cas extrême, car généralement pendant une journée de négociation, je dois mettre à jour environ 1 000 lignes toutes les 5 secondes (c'est donc la contrainte la plus réaliste à laquelle je fais face).

Autres paramètres mysql.cnf pertinents que j'ai modifiés:

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

BTW si au lieu d'Innodb je crée la table avec ENGINE = MEMORY il faut environ 4 secondes pour faire l'insertion, 6 secondes pour faire la mise à jour.

Beaucoup de TIA si quelqu'un peut m'aider à déterminer quelle est la référence pour ce type de requête, ou m'aider à améliorer le temps.

Don

Paramètres PS Innodb complets.

mysql> affiche les variables globales comme 'innodb%';
+ ------------------------------------------- + ----- ------------------- +
| Nom_variable | Valeur |
+ ------------------------------------------- + ----- ------------------- +
| innodb_adaptive_flushing | ON |
| innodb_adaptive_flushing_method | estimation |
| 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 | tout |
| innodb_checkpoint_age_target | 0 |
| innodb_checksums | ON |
| innodb_commit_concurrency | 0 |
| innodb_concurrency_tickets | 500 |
| innodb_corrupt_table_action | affirmer |
| innodb_data_file_path | ibdata1: 10M: extension automatique |
| 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_neighbors_pages | zone |
| 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 | linéaire |
| 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 lignes en jeu (0,00 sec)

J'ai exécuté numactl --hardware et voici la sortie que j'ai obtenue. Les commentaires de mon administrateur sont notés ci-dessous (en ce qui concerne l'interprétation).

root @ prog: / data / mysql # numactl --hardware
disponible: 4 nœuds (0-3)
noeud 0 cpus: 0 1 2 3
taille du nœud 0: 32766 Mo
noeud 0 libre: 21480 Mo
nœud 1 cpus: 4 5 6 7
taille du nœud 1: 32768 Mo
noeud 1 libre: 25285 Mo
noeud 2 cpus: 12 13 14 15
taille du nœud 2: 32768 Mo
noeud 2 gratuit: 20376 Mo
noeud 3 cpus: 8 9 10 11
taille du nœud 3: 32768 Mo
noeud 3 gratuit: 24898 Mo
distances des nœuds:
noeud 0 1 2 3
  0: 10 16 16 16
  1:16 10 16 16
  2: 16 16 10 16
  3: 16 16 16 10

Vous devez régler vos paramètres InnoDB dans les domaines suivants:

• Faites en sorte qu'InnoDB accède à tous vos cœurs
• Augmentez innodb_buffer_pool_size à 12G
• Augmentez innodb_buffer_pool_instances à 2 (exécutez d'abord numactl --hardwarepour déterminer le nombre de CPU physiques. Ce que chaque nombre de CPU qu'il rapporte, utilisez ce nombre. J'ai appris cela récemment dans le blog de Jeremy Cole )
• Augmentez la taille du fichier journal ( innodb_log_file_size ) à 2047 Mo
• prendre en charge des fichiers d'espace de table distincts pour les tables InnoDB individuelles (enaled innodb_file_per_table )
• prendre en charge des performances élevées ou une durabilité élevée (conformité ACID)
  • Haute performance: innodb_flush_log_at_trx_commit défini sur 0 ou 2
  • Haute durabilité: innodb_flush_log_at_trx_commit défini sur 1 (par défaut)
  • Augmentez la taille de innodb_log_buffer_size en conjonction avec le nombre de transactions par seconde (peut-être 32M)
  • Votre paramètre actuel pour innodb_flush_log_at_trx_commit est bon
  • Votre paramètre actuel pour innodb_flush_method est bon
• Augmentez innodb_read_io_threads à 64
• Augmentez innodb_write_io_threads à 64
• Augmentez innodb_io_capactity à 10000

Voici mes précédents articles sur le réglage du moteur de stockage InnoDB

• Les performances du processeur sont-elles pertinentes pour un serveur de base de données? (26 avr.2012)
• Pourquoi InnoDB stocke-t-il toutes les bases de données dans un seul fichier? (25 mars 2012)
• Multi-cœurs et performances MySQL (20 sept. 2011)
• Est-il possible que MySQL utilise plus d'un cœur? (12 sept. 2011)
• À propos des performances des bases de données monothread et multithread (26 mai 2011)
• Comment changer en toute sécurité la variable innodb MySQL 'innodb_log_file_size'? (16 févr.2011)
• Comment régler MySQL pour une lourde charge de travail InnoDB? (12 févr.2011)
• Comment: nettoyer un moteur de stockage mysql InnoDB? (29 octobre 2010)