2 votes

Problèmes de performance de MySQL après la mise à niveau du matériel et le passage à la VM

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 : slow_query 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 :

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 ?

2voto

shodanshok Points 42743

Vous n'avez pas spécifié le type de cache du disque virtuel, donc libvirt suppose le schéma de cache le plus sûr : directsync ce qui implique que toutes les écritures sont immédiatement synchronisées sur le disque physique.

Un type de cache aussi restrictif est généralement inutile pour les applications modernes qui tiennent compte du cache et qui utilisent les barrières d'écriture pour garantir que les écritures importantes sont synchronisées avec le disque.

Faites ce qui suit :

  • éteindre votre machine
  • ouvrir sa configuration via virt-manager
  • sélectionnez virtio disk 1 et, dans le volet de droite, cliquez sur advanced entonces performance options
  • définir le type de cache sur writeback
  • enfin, redémarrez votre machine virtuelle.

La VM devrait être beaucoup plus rapide maintenant. Cependant, comme vous utilisez un système d'exploitation assez ancien (CentOS 5.x), veillez à activer les barrières d'écriture dans le système d'exploitation invité. Pour ce faire, vous devez monter le système de fichiers de votre invité avec la commande barrier=1 option de montage (par exemple, en le passant par /etc/fstab ).

Pour d'autres informations sur la mise en cache et les barrières, Jetez un coup d'œil ici

0 votes

Merci pour votre réponse. Je ne peux pas le faire pour l'instant car il y a des gens qui utilisent le serveur, mais je vous ferai savoir si cela a fonctionné !

0 votes

N'oubliez pas d'activer les barrières à l'intérieur du système d'exploitation invité via l'option barrier=1 option de montage - il est très important d'éviter la perte de données en cas de panne du système.

0 votes

Les barrières d'habilitation n'empêchent pas la perte de données, mais garantissent l'intégrité du système de fichiers en cas de panne - ce qui n'est pas du tout la même chose. Et essayer de s'assurer qu'un seul nœud est aussi fiable que possible est rarement une bonne solution pour l'AH.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X