web-dev-qa-db-fra.com

Très pauvre insertion Performance MySQL / PerCona Server

Je suis une instance Percona-Server sur une installation de serveur Ubuntu. J'utilise une application qui doit accéder à cette base de données, et sa performance très médiocre. Une fois la base de données établie, l'application se déroule (à l'installation) et crée le schéma. Il fait défaut tout à Myisam, mais j'ai converti les moteurs de la table à InnoDB. La question que j'ai eu est une performance d'insertion très mauvaise. Cette application est très écrite, et il semble que cela puisse écrire chaque rangée 1 à la fois sur le disque, n'utilisant aucune sorte de tampons, mais je ne sais pas comment vérifier ou vérifier cela. Même une sélection (*) de l'une des tables prendra 2,4 secondes et il n'y a que 163 000 rangées. Je suis un peu à perte de ce que je peux faire d'autre.

Le serveur a 8 Go de RAM et la CPU est presque entièrement inactive pendant que cela se produise.

my.cnf:

[mysql]

# CLIENT #
port                           = 3306
socket                         = /var/run/mysqld/mysqld.sock

[mysqld]

# GENERAL #
user                           = mysql
default_storage_engine         = InnoDB
socket                         = /var/run/mysqld/mysqld.sock
pid_file                       = /var/run/mysqld/mysqld.pid

# MyISAM #
key_buffer_size                = 32M
myisam_recover                 = FORCE,BACKUP

# SAFETY #
max_allowed_packet             = 16M
max_connect_errors             = 1000000
skip_name_resolve
sql_mode                       = STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_AUTO_VALUE_ON_ZERO,NO_ENGINE_SUBSTITUTION,NO_ZERO_DATE,NO_ZERO_IN_DATE,ONLY_FULL_GROUP_BY
sysdate_is_now                 = 1
innodb                         = FORCE
innodb_strict_mode             = 1

# DATA STORAGE #
datadir                        = /mnt/Storage/mysql/

# BINARY LOGGING #
log_bin                        = /mnt/Storage/mysql/mysql-bin
expire_logs_days               = 14
sync_binlog                    = 1

# CACHES AND LIMITS #
tmp_table_size                 = 32M
max_heap_table_size            = 32M
query_cache_type               = 0
query_cache_size               = 0
max_connections                = 500
thread_cache_size              = 50
open_files_limit               = 65535
table_definition_cache         = 1024
table_open_cache               = 2048

# INNODB #
innodb_flush_method            = O_DIRECT
innodb_log_files_in_group      = 2
innodb_log_file_size           = 512M
innodb_flush_log_at_trx_commit = 0
innodb_file_per_table          = 1
innodb_buffer_pool_size        = 6144M
innodb_buffer_pool_instances   = 1
innodb_read_io_threads         = 64
innodb_write_io_threads        = 64
innodb_io_capacity             = 10000

# LOGGING #
log_error                      = /mnt/Storage/mysql/mysql-error.log
log_queries_not_using_indexes  = 1
slow_query_log                 = 1
slow_query_log_file            = /mnt/Storage/mysql/mysql-slow.log

desc d'une table qui a une mauvaise performance d'insertion:

mysql> desc parts;
+------------+---------------------+------+-----+---------+----------------+
| Field      | Type                | Null | Key | Default | Extra          |
+------------+---------------------+------+-----+---------+----------------+
| ID         | bigint(20) unsigned | NO   | PRI | NULL    | auto_increment |
| binaryID   | int(11) unsigned    | NO   | MUL | 0       |                |
| messageID  | varchar(255)        | NO   |     |         |                |
| number     | bigint(20) unsigned | NO   | MUL | 0       |                |
| partnumber | int(10) unsigned    | NO   |     | 0       |                |
| size       | bigint(20) unsigned | NO   |     | 0       |                |
| dateadded  | datetime            | YES  | MUL | NULL    |                |
+------------+---------------------+------+-----+---------+----------------+
7 rows in set (0.00 sec)
3
Tony

Observation n ° 1

Étant donné que votre piscine tampon est de 6g (6144 m), le innodb_log_file_size devrait être de 1536m (25% de 6g)

Observation n ° 2

Vous avez sync_binlog défini sur 1. Ceci fournit la configuration conforme à l'acide la plus sûre. Cela peut aussi réduire considérablement les choses. Vous dites it seems as though its writing each row 1 at a time to disk. C'est le cas car chaque instruction DML (Insert, Mettre à jour, Mettre à jour, Delete) et DDL (Alter Table) est écrite sur les journaux binaires. La valeur par défaut pour sync_binlog est 0. Cela permettrons au système d'exploitation des modifications du journal binaire de chasse au disque.

Observation n ° 3

Vous avez innodb_io_capacity Ensemble à 10000. C'est vraiment 10000 iops que vous attendez de MySQL. Essayez de baisser.

Il y a des choses à faire à cet égard

  • Quand il s'agit de sync_binlog
    • Commentiez-le hors de my.cnf
    • Définir Sync_binlog sur 100 ou 200 pour allonger le rinçage des bûches binaires
  • Vous devez vous assurer que le disque de données dispose d'un cache sauvegardé par batterie (avec une bonne batterie)

RECOMMANDATION

Étape 01) Définissez ces options dans my.cnf

[mysqld]
innodb_fast_shutdown = 0
innodb_log_file_size = 1536M
sync_binlog = ( you choose 0 or 100 )

Étape 02) Supprimer innodb_io_capacity . Laissez-le être défini sur défaut.

Étape 03) Exécutez cette commande dans MySQL

mysql> SET GLOBAL innodb_fast_shutdown = 0;

Étape 04) Appliquer les paramètres

cd /mnt/Storage/mysql
service mysql stop
mv ib_logfile0 ib_logfile0.bak
mv ib_logfile2 ib_logfile1.bak
service mysql start

Cela devrait accélérer les choses

6
RolandoMySQLDBA