Usuários reclamam que o sistema fica lento quando o mysqldump está em andamento

O banco de dados MYSQL (ibdata1) tem tamanho de 73 GB e está configurado para ser executado como um servidor de banco de dados dedicado no Windows 2008 O / S para tabelas INNODB. Estamos executando o backup usando o mysqldump mysqldump --skip-opt --quick - única transação --create-options --extended-insert --disable-keys --add-drop-table --complete-insert - set-charset - compactar --log-error = Proddb0635.err -u raiz -pjohndoe Proddb> \ devNas \ devNas \ sqlbackup \ LIVE \ db \ Proddb0635.sql

O arquivo de backup Proddb0635.sql é armazenado em um servidor separado do servidor de banco de dados. RAM é de 12 GB. O tamanho do buffer pool do INNODB é 6 GB. Mem.pool adicional é de 32 MB. O tamanho do cache de consulta é 2 GB. O comprimento do buffer líquido é 16 M máx. tamanho do pacote 1 GB.

A versão do mysql é 5.0.67.

Quando o backup não está sendo executado, os usuários ficam satisfeitos com o desempenho.

Quando o backup está sendo executado, a taxa de acertos do buffer pool do INNODB é alta perto de 100%. Não há leituras ou gravações pendentes. innodb wait free é 0. O uso da CPU não é alto min 9% a max 15% A taxa de acertos do cache de consultas é baixa em cerca de 40% com ou sem o mysqlbackup em execução. Atualmente, o Windows Task Manager está exibindo que 10 GB de RAM estão sendo usados. Devo aumentar o cache de consulta com apenas 2 GB de RAM disponível? O mysqlld-nt está usando 9.2 GB de RAM e o mysqldump está usando 5 MB de RAM. Alos, observou que o tamanho do arquivo de despejo é o mesmo na presença ou ausência da opção --compress.

DEVO diminuir o tamanho do buffer pool do iNNODB?

obrigado

Há um problema conhecido no Windows: quando você envia um arquivo grande para outro servidor, toda a memória acaba sendo alocada no cache do sistema, em vez dos processos do usuário. Você pode procurar na seção Memória física (MB) do gerenciador de tarefas para ver quanta memória está alocada no cache do sistema.

Isso pode ser resolvido fazendo backup em um disco local e solicitando à máquina remota que puxe esse arquivo.

Aqui estão alguns pensamentos que tenho sobre como melhorar o desempenho do mysqldump, dadas as suas circunstâncias. Aqui está o seu comando:

mysqldump - skip-opt --quick - única transação - criar opções - extensão extendida - chaves descartáveis ​​- adicionar tabela suspensa - inserção completa de inserção - inserção completa - conjunto de caracteres - compactação - -log-error = Proddb0635.err -u raiz -pjohndoe Proddb> \ devNas \ devNas \ sqlbackup \ LIVE \ db \ Proddb0635.sql

A primeira coisa que noto é que você está redirecionando a saída para um sistema de arquivos. Ele diz 'devNas', então vou assumir que esse é o armazenamento anexado à rede . Sou fã do NAS para backups, mas ele deve estar conectado em uma NIC física separada do tráfego de produção . Você pode não estar saturando a largura de banda, mas eles ainda competem. Isso será mais um problema por causa do sinalizador --quick, pois ele libera todas as linhas em vez de mantê-lo na memória.

A próxima coisa que vejo é que você invocou --compress. Parece que você está executando o mysql localmente, pois não usou a opção -h. Isso pode usar a CPU local desnecessária nesse contexto. --Compress é necessário? Ele comprime apenas os dados entre o cliente mysqldump e o servidor mysql, não o conteúdo do arquivo.

Em seguida, vejo que você está usando o sinalizador - única transação. Isso causará CPU extra, uma vez que é testado em cada seleção como parte do mysqldump.

Isso não tem nada a ver com desempenho, mas você está usando --disable-keys, que só funciona no MyISAM ( manual ).

Você pode experimentar executar o mysqldump remotamente a partir de um host offline e mover o arquivo de despejo para o NAS após a conclusão, para tirar o máximo dessa operação fora de banda possível.

OBSERVAÇÃO Nº 1

Aqui está algo a ter em mente ao executar um mysqldump no InnoDB.

Quaisquer páginas sujas que existam no InnoDB Buffer Pool devem ser lavadas primeiro no disco. Um mysqldump irá disparar a liberação de uma tabela do InnoDB que ainda possui páginas sujas.

Há uma opção de servidor chamada innodb_max_dirty_pages_pct . O valor padrão é 75 é MySQL 5.5 e 90 nas versões do MySQL anteriores à 5.5. Em um ambiente de produção, não há problema em deixar esse número no valor padrão.

Para ver se você tem muitas páginas sujas no InnoDB Buffer Pool, execute o seguinte:

SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_pages_dirty';

Entre uma página é 16K como mostra isto:

SHOW GLOBAL STATUS LIKE 'Innodb_page_size';

Quando se trata do InnoDB e do mysqldump, você pode diminuir esse número em duas circunstâncias.

CIRCUNSTÂNCIA 1: defina-a permanentemente para 0

Basta adicionar isso ao my.ini:

[mysqld]
innodb_max_dirty_pages_pct=0

Isso manterá o InnoDB Buffer Pool baixo e médio. A etapa de liberar a tabela do InnoDB que está sendo descartada será rápida, porque poucas páginas sujas quanto possível (talvez 0) precisarão ser liberadas antes que o mysqldump opere.

A única desvantagem é que se você mysqldump de um banco de dados altamente trafegado, pode haver um aumento menor na E / S de gravação por causa da descarga da página suja com mais freqüência. Você pode determinar se é assim sem reiniciar o mysql executando este:

SET GLOBAL innodb_max_dirty_pages_pct = 0;

Deixe a configuração por 12 a 24 horas, se o desempenho de gravação for aceitável, você estará pronto. Caso contrário, configure-o novamente com:

SET GLOBAL innodb_max_dirty_pages_pct = 90;

CIRCUNSTÂNCIA 2: Defina como 0 cerca de 1 hora antes do mysqldump

SET GLOBAL innodb_max_dirty_pages_pct = 0;

Execute o mysqldump

SET GLOBAL innodb_max_dirty_pages_pct = 90;

OBSERVAÇÃO Nº 2

Você tem --complete-insert como uma opção mysqldump. Isso incorporará nomes de colunas a todos os estatutos INSERT antes da cláusula VALUES. Mesmo com --extended-insert, em cada lote de linhas sendo inseridas, os nomes das colunas são enviados para o mysqldump. Você pode reduzir a quantidade de bytes enviados para o mysqldump removendo --complete-insert.

RECOMENDAÇÃO

Se você possui outro Windows Server que pode ser configurado como escravo, execute o mysqldumps desse escravo, e não da máquina de produção.