Capacités des performances InnoDB INSERT


11

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

Réponses:


9

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

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


Merci pour cette réponse incroyablement utile !! Je vous salue. En ce qui concerne la taille du journal, dois-je m'inquiéter de le rendre trop gros? ma préoccupation est quelque chose que Tkachenko a écrit sur mysqlperformanceblog.com/2011/09/18/disaster-mysql-5-5-flushing . Je me rends compte que je suis sur Percona, alors peut-être que ce n'est pas un problème .. mais je veux être sûr de ne pas tomber dans un scénario de décrochage. Je fouille dans le reste de votre réponse ...
Don Wool

ce qui concerne innodb_buffer_pool_instances J'ai une boîte de 16 cpu (j'avais pensé que c'était 10). en ce qui concerne numactl mon administrateur dit "Vous avez 16 processeurs au total et quatre blocs de RAM, 32 Go chacun. Chaque bloc de RAM est traité comme mémoire locale par quatre processeurs."
Don Wool

Veuillez exécuter numactl --hardwareet publier la sortie dans la question. J'essaie de comprendre les CPU physiques et je veux m'assurer que l'administrateur ne dit pas CPU quand il veut dire cœurs.
RolandoMySQLDBA

Ok j'ai posté la sortie de 'numactl' dans la question.
Don Wool

Pour moi, la sortie ressemble à un quadruple cœur (16 cœurs) utilisant 4 processeurs. Par conséquent, définissez innodb_buffer_pool_instances=4. Encore une demande: veuillez vérifier, le serveur DB a-t-il 64 Go ou 128 Go ???
RolandoMySQLDBA
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.