Problemas de desempenho do MySQL após atualização de hardware e mudança para VM

Question

Recentemente, executamos algumas atualizações (de segurança) em nossos servidores e reinicializamos as máquinas. Nosso servidor de desenvolvimento não ficou mais online devido a um problema com a GPU (integrada na CPU). Substituímos (e atualizamos) o hardware nessa máquina e também convertemos a máquina originalmente bare-metal em uma VM (KVM) para que possamos atualizá-la a partir do CentOS5 - > CentOS6 depois.

No entanto, a máquina em si NÃO foi reinstalada, todos os dados foram protegidos e copiados 1: 1 como uma nova imagem que a (nova) VM poderia usar para inicializar.

O problema que temos agora é o desempenho do MySQL. Parece estar relacionado principalmente a instruções CREATE TABLE realmente simples. Não podemos encontrar se esse problema está relacionado à atualização do MySQL para 5.5.50 ou a mudança para uma VM.

O problema:

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 ;

(nosso pacote unittest cria uma estrutura de banco de dados e esta é uma tabela criada)

Você notará que levou quase 8 segundos para criar esta tabela! (Nossa suíte de testes agora leva 2 minutos ao invés de 30 segundos)

Eu também executei esta consulta com o perfil:

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;

E esta é a saída: Osresultadosvariam,masvejomuitosvaloresaltos(>1seg)),naminhaopinião,issonuncadevelevarmaisdeumsegundoemumservidorcompoucacarga.

Eutenteifazeralgumasalteraçõesnomy.conf,masaindanãoconseguiaumentarodesempenho.Envieinosso my.cnf para referência.

Alguns detalhes no servidor:

• MySQL 5.5.50
• CentOS 5.11

Anfitrião:

• i7 6300
• 32 GB de RAM
• 2 x disco rígido de 1 TB

VM:

• 4 núcleos
• 16 GB de RAM

Eu não posso acreditar que isso seja apenas a partir do zero-metal = > VM. Alguém pode nos apontar na direção certa? Se mais informações forem necessárias, me avise.

Informações adicionais:

• Configuração da VM:
• CPU Load: baixa (~ 5%)
Saída de iostat
• durante a execução: link

Answer 1

Você não especificou o tipo de cache vdisk, portanto a libvirt está assumindo o esquema de cache mais seguro: directsync , o que implica que todas as gravações são imediatamente sincronizadas com o disco físico.

Esse tipo de cache restritivo é geralmente um exagero para um aplicativo moderno, com reconhecimento de cache, que usa barreiras de gravação por si só para garantir que gravações importantes sejam sincronizadas com o disco.

Faça o seguinte:

• desligue sua máquina
• abra sua configuração via virt-manager
• selecione virtio disk 1 e, no painel direito, clique em advanced e, em seguida, em performance options
• defina o tipo de cache como writeback
• finalmente, reinicie sua máquina virtual.

A VM deve ser muito mais rápida agora. No entanto, como você está usando um sistema operacional bastante antigo (CentOS 5.x), certifique-se de ativar as barreiras de gravação dentro do sistema operacional convidado. Para fazer isso, você deve montar o sistema de arquivos do seu convidado com a opção barrier=1 mount (por exemplo: passá-lo via /etc/fstab ).

Para algumas outras informações sobre caching e barreiras, dê uma olhada aqui