Eu tenho uma configuração MySQL (na verdade, MariaDB 5.2) implementada em um nó Rackspacecloud 4Gb. Todas as tabelas são InnoDB, o tamanho do conjunto de buffers do InnoDB é 2G e está 95% cheio na maioria das vezes. Eu uso o ext3 como um sistema de arquivos (não tenho certeza se posso usar qualquer outra coisa em um nó de nuvem). Meu aplicativo faz muitas gravações em duas tabelas de estatísticas. Ambas as tabelas têm um PK auto_increment e um índice exclusivo. Essas tabelas são limpas a cada 10 minutos por um cron job. Esta tarefa cron também faz várias consultas de longa duração para processar estatísticas brutas.
O problema é que eu obtenho altos picos de E / S de tempos em tempos. Parece que eles estão relacionados a um número de bytes não detectados no log de transações do InnoDB. O número médio de bytes não selecionados é 18.6M, mas chega a 80-90M quando vejo esses picos. Não sei o que causa o que aqui.
Iotop mostra que o kjournald é o melhor desempenho quando esses picos ocorrem. Eu remontei o FS com a opção "data = writeback", mas sem sucesso, o kjournald ainda estava no topo. Eu também tentei diminuir o swappiness e aumentar o queue / nr_requests para o dispositivo root, mas isso também não ajudou.
Não sei o que fazer a seguir. Gostaria de saber por que o kjournald gera uma carga de E / S tão grande em um FS com apenas metadados sendo registrados em diário. Devo tentar ajustar um intervalo de confirmação? Ou provavelmente usar ionização?
80-90M
Está próximo do tamanho do diário padrão do EXT3. Parece que fica cheio, então ele começa a liberá-lo. A resposta é altamente dependente do quanto você se preocupa com a consistência do sistema de arquivos, pois isso oferece muitas opções, ou algumas delas.
Além disso, se essas tabelas de estatísticas forem "limpas a cada 10 minutos", por que não tê-las na memória?