Acabei de ler este antigo Q & A, que tinha algumas informações detalhadas realmente boas sobre uma configuração semelhante à nossa, embora infelizmente nosso problema (agora) não seja com a replicação.
Desempenho de replicação do MySQL
Temos um novo servidor de banco de dados mestre (Versão do servidor: 5.5.27 -log MySQL Community Server) que está em um servidor bare-metal com as seguintes especificações:
- 2 x Intel E5-2620-v2
- Memória de 64 GB
- 2 x placa Fusion-io de 600 Gb (Raid 1) para MySql
- 1 x SSD para o Centos 6.5
- Rede de 1 Gbps
O HyperThreading não foi desativado no servidor, pois há opiniões divergentes sobre se isso ajuda em grandes sistemas de memória, mas não somos contra isso.
Atualmente, replicamos para 3 escravos que são virtualizados em um cluster SSD. Estávamos replicando para 4, mas isso parecia demais para o cluster SSD e tivemos períodos de defasagem.
Todas as tabelas são InnoDB e DB principal e escravo Gravações estão entre 3.5K - 2.5K qps , enquanto Lê no master são sobre 7,5k - 10k qps .
As configurações para o banco de dados mestre são as seguintes:
long-query-time=10
slow-query-log
max_connections=500
max_tmp_tables=1024
key_buffer = 1024M
max_allowed_packet = 32M
net_read_timeout=180
net_write_timeout=180
table_cache = 512
thread_cache = 32
thread_concurrency = 4
query_cache_type = 0
query_cache_size = 0M
innodb_file_per_table
innodb_file_format=barracuda
innodb_buffer_pool_size=49152M
innodb_buffer_pool_instances=2
innodb_read_io_threads=16
innodb_write_io_threads=16
innodb_io_capacity = 500
innodb_additional_mem_pool_size=20M
innodb_log_file_size=1024M
innodb_log_files_in_group = 2
innodb_doublewrite=0
innodb_flush_log_at_trx_commit=2
innodb_flush_method=O_DIRECT
Nosso problema é com a carga da CPU, especialmente o Sys Cpu. Como você pode ver no mpstat, temos 0% iowait e muito alto% sys.
Linux 2.6.32-431.29.2.el6.x86_64 13/11/14 _x86_64_ (24 CPU)
13:57:18 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
13:57:19 all 23.35 0.00 74.65 0.00 0.00 0.88 0.00 0.00 1.13
13:57:20 all 21.95 0.00 75.50 0.00 0.00 0.96 0.00 0.00 1.59
13:57:21 all 23.74 0.00 72.63 0.00 0.00 1.00 0.00 0.00 2.63
13:57:22 all 23.88 0.00 71.64 0.00 0.00 1.17 0.00 0.00 3.31
13:57:23 all 23.26 0.00 73.89 0.00 0.00 0.92 0.00 0.00 1.92
13:57:24 all 22.87 0.00 74.87 0.00 0.00 1.00 0.00 0.00 1.25
13:57:25 all 23.41 0.00 74.51 0.00 0.00 0.96 0.00 0.00 1.12
Anteriormente, o banco de dados mestre estava sendo executado em um servidor virtualizado (mesmo cluster SSD que os escravos). Ele tinha um host para si mesmo no cluster do vSphere que tinha:
- 2 x Intel X5570
- 32 GB de memória
- SSD compartilhado do cluster
Nunca houve nenhum problema antes, o servidor funcionou sem falhas por muitos anos, embora com menor taxa de transferência de SQL.
As consultas são simples e os índices foram otimizados para inserções & atualizações como consultas complexas do cliente são realizadas nos escravos. Não há exclusões, apenas inserções & atualizações. A maioria das tabelas (todas grandes) tem chaves primárias.
O uso da CPU parece aumentar quando o buffer de memória está cheio e o MySql é o único aplicativo sendo executado no servidor.
As conexões variam de cerca de 200 a 400, com cerca de 100 a 200 delas. A taxa de acertos do pool de buffers do Innodb é 100%. Não há memória de troca alguma vez sendo criada, por isso não vejo esse problema:
link
Temos uma tonelada de história com o New Relic, mas infelizmente não posso colar screenshots aqui.
Eu já passei por inúmeros blogs e perguntas e respostas. Como assim, mas não consigo encontrar nenhuma causa nem solução, estou colocando isso para fora ... Alguma idéia?
UPDATE
Parece que agora posso postar capturas de tela. Essas duas capturas de New relic mostram a carga do sistema e a carga de consulta no servidor em uma janela de 6 horas com uma reinicialização do mysql no meio.
