Récemment, nous avons effectué quelques mises à jour (de sécurité) sur nos serveurs et redémarré les machines. Notre serveur de développement n'était plus en ligne en raison d'un problème avec le GPU (intégré au CPU). Nous avons remplacé (et mis à niveau) le matériel sur cette machine et avons également converti la machine bare-metal d'origine en une VM (KVM) afin de pouvoir la mettre à niveau de CentOS5 -> CentOS6 plus tard.
Cependant, la machine elle-même n'a PAS été réinstallée, toutes les données ont été sécurisées et copiées 1:1 sous la forme d'une nouvelle image que la (nouvelle) VM pouvait utiliser pour démarrer.
Le problème que nous avons maintenant est la performance de MySQL. Il semble être principalement lié à des instructions CREATE TABLE très simples. Nous n'arrivons pas à déterminer si ce problème est lié à la mise à niveau de MySQL vers la version 5.5.50 ou au passage à une VM.
Le problème :
mysql-slow-querylog
# Time: 160610 13:55:50
# User@Host: unittest[unittest] @ localhost [127.0.0.1]
# Query_time: 7.954247 Lock_time: 0.000049 Rows_sent: 0 Rows_examined: 0
use unittest_api_575aaabd9e502;
SET timestamp=1465559750;
-- --------------------------------------------------------
--
-- Table structure for table `customer`
--
CREATE TABLE IF NOT EXISTS `customer` (
`customer_id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(255) NOT NULL,
`crm_id` varchar(255) DEFAULT NULL,
PRIMARY KEY (`customer_id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=25 ;
(notre suite d'unittest crée une structure DB et ceci est une table qui est créée)
Vous remarquerez qu'il a fallu presque 8 secondes pour créer ce tableau ! (Notre test-suite prend maintenant 2 minutes au lieu de 30 secondes)
J'ai également exécuté cette requête avec le profilage :
DROP TABLE IF EXISTS `customer`;
set profiling =1;
CREATE TABLE IF NOT EXISTS `customer` (
`customer_id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(255) NOT NULL,
`crm_id` varchar(255) DEFAULT NULL,
PRIMARY KEY (`customer_id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=25;
set profiling =0;
show profile all for query 1;
Et voici le résultat : Les résultats varient mais je vois beaucoup de valeurs élevées (>1 sec)), à mon avis cela ne devrait jamais prendre plus d'une seconde sur un serveur peu chargé.
J'ai essayé d'apporter quelques modifications à my.conf mais je n'ai pas encore réussi à augmenter les performances. J'ai téléchargé notre mon.cnf pour référence.
Quelques détails sur le serveur :
- MySQL 5.5.50
- CentOS 5.11
Hôte :
- i7 6300
- 32GB RAM
- 2 disques durs de 1 To
VM :
- 4 cœurs
- 16GB RAM
Je ne peux pas croire qu'il s'agit uniquement de bare-metal => VM. Quelqu'un peut-il nous indiquer la bonne direction ? Si vous avez besoin de plus d'informations, faites-le moi savoir.
Informations complémentaires :
- VM Config :
- Charge du CPU : faible (~5%)
- Sortie iostat pendant l'exécution : http://pastebin.com/AHkby04X
0 votes
Pouvez-vous montrer la sortie de
virsh dumpxml <vmname>
?0 votes
@shodanshok Voilà : pastebin.com/0tfYiaE2
0 votes
Avez-vous vérifié l'iowait et la charge du processeur pendant le test ?
1 votes
"2 x 1TB harddisk" - lent, IOPS terrible, inapte à exécuter la virtualisation de base de données (ou n'importe quelle base de données) avec n'importe quelle exigence de performance.
0 votes
Oui, les disques durs sont lents par rapport aux disques SSD, mais il s'agit d'un serveur de développement. Nous n'avons jamais eu de problèmes (comme celui-ci) auparavant. La base de données est vraiment peu utilisée. Je m'interroge ici sur la différence entre la situation avant et après le remplacement du disque dur et la conversion de la VM. Oui, les performances ne seront pas aussi bonnes que lorsque le serveur était à nu, mais elles ne devraient pas être si mauvaises qu'une simple déclaration CREATE TABLE prenne 8 secondes !
0 votes
@NikitaKipriyanov Je suis désolé de ne pas avoir remarqué votre réponse avant. La charge du CPU est faible, comme il s'agit d'un CPU rapide avec 4 cœurs affectés à la VM, elle se situe autour de ~5% de chaque cœur. Je ne remarque pas de réelle différence de charge pendant la partie "CREATE TABLE" du test. L'IOwait ("xx% wa en haut à droite ?) est à ~30% Je ne sais pas si c'est mauvais.
0 votes
@NikitaKipriyanov J'ai mis à jour la question avec la sortie iostat.