O MySQL está eliminando o servidor IO [duplicado]

Question

Eu gerencio fóruns de vBulletin razoavelmente grandes / ocupados (rodando em nuvem gigenet), o banco de dados é ~ 10 GB (~ 9 milhões posts, ~ 60 consultas por segundo), ultimamente o MySQL tem triturado o disco como se não houvesse amanhã de acordo para iotop e abrandar o site.

A última idéia que posso imaginar é usar replicação, mas não tenho certeza de quanto isso ajudaria e me preocuparia com a sincronização do banco de dados.

Estou sem ideias, qualquer sugestão de como melhorar a situação seria muito apreciada.

Especificações:

Debian Lenny 64bit
~12Ghz (6 cores) CPU, 7520gb RAM, 160gb disk.  
Kernel : 2.6.32-4-amd64  
mysqld  Ver 5.1.54-0.dotdeb.0 for debian-linux-gnu on x86_64 ((Debian))  

Outro software:

vBulletin 3.8.4
memcached 1.2.2
PHP 5.3.5-0.dotdeb.0 (fpm-fcgi) (built: Jan  7 2011 00:07:27)
lighttpd/1.4.28 (ssl) - a light and fast webserver

PHP e vBulletin estão configurados para usar o memcached.

Configurações do MySQL:

[mysqld]
key_buffer              = 128M
max_allowed_packet      = 16M
thread_cache_size       = 8
myisam-recover         = BACKUP
max_connections        = 1024
query_cache_limit       = 2M
query_cache_size        = 128M
expire_logs_days        = 10
max_binlog_size         = 100M

key_buffer_size = 128M
join_buffer_size = 8M
tmp_table_size = 16M
max_heap_table_size = 16M
table_cache = 96

Outro:

> vmstat
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 9  0  73140  36336   8968 1859160    0    0    42    15    3    2  6  1 89  5

> /etc/init.d/mysql status
Threads: 49  Questions: 252139  Slow queries: 164  Opens: 53573  Flush tables: 1  Open tables: 337  Queries per second avg: 61.302.

Editar Informações adicionais.

    

Answer 1

Primeiro, embora seja apenas relacionado de forma tangencial, você provavelmente deve procurar mudar do MyISAM para o InnoDB. Ele terá um desempenho melhor sob o tipo de concorrência que você provavelmente tem e é muito menos provável que perca dados no caso de uma falha.

Quanta memória você está alimentando na instância do memcached? Aumentar isso pode ajudar se as suas expulsões e erros forem altas, mas isso exigirá alguma experimentação.

128 MB é definitivamente muito baixo de um key_buffer considerando o tamanho do seu conjunto de dados e a RAM disponível. Eu diria que deveria ser mais como 1-2GB se você puder poupar a RAM (ou, se você mudar para o InnoDB, substituir "key_buffer" por "InnoDB buffer pool size"). Seus "blocos em" são 3x seus blocos fora, o que provavelmente significa que o MySQL está tendo que acertar o disco para uma porção significante das leituras. Você pode usar o mysqltuner ou as estatísticas no phpmyadmin para ver se coisas como o buffer de classificação, etc. precisam ser ajustadas, mas elas provavelmente não são o maior problema.

Verifique suas estatísticas detalhadas, como taxa de hits no cache de consulta. Há uma boa chance de que você não esteja fazendo nada de bom e deva ser desativado, especialmente porque você também está usando o memcache.

A boa notícia é que você é obrigado a ler em vez de escrever, o que significa que você pode melhorar o desempenho com relativa facilidade por meio de cache. Na pior das hipóteses, se você não tiver memória RAM suficiente para aumentar key_buffer ou memcached e não conseguir expandir seu servidor atual, poderá mover o lighttpd e o memcached para um servidor próximo separado e dedicará todo o ~ 8GB ao MySQL. Com um conjunto de dados de 10 GB, isso será suficiente. Não há necessidade de recorrer a um escravo de replicação por causa do desempenho, embora, como outra pessoa mencionou, seja benéfico para backups e failover.

    

Answer 2

Independentemente de você poder reduzir a sobrecarga, eu recomendaria a replicação do MySQl para um servidor secundário. Com alguns balanceadores de carga, você pode diminuir drasticamente o tempo de inatividade e facilitar a carga no servidor. Apenas um pensamento. Mensagem-me se você quiser alguma orientação sobre como configurar a replicação.

    

Answer 3

Se o tráfego do seu fórum é parecido com o tráfego que presenciei no gerenciamento do vBulletin, você não deve invocar PHP ou MySQL para 50-75% das solicitações (ou seja, mais da metade dos pedidos vêm de "lurkers" não autenticados).

Dê uma olhada na implementação de um proxy reverso para usuários não autenticados, caso você ainda não tenha feito isso - a menos que você tenha feito algumas modificações sérias no vBulletin, usuários não-autenticados não verão nenhum conteúdo dinâmico de qualquer maneira.

Atualização: Leitura relacionada: Como configurar o Nginx como um proxy reverso de cache?

    

Answer 4

Se você tem 8GB de RAM, os valores de memória que você tem para o servidor mysql parecem pequenos. Seu banco de dados e servidor da web estão no mesmo host? A solução simples pode ser apenas configurar um segundo host e separar a Web e os serviços de banco de dados, se você ainda não o fez.

    

Answer 5

Esse é um problema típico de SQL (irrelevante, seja oracle, sql-server, mysql).

Bancos de dados estão ligados. Ter muitos discos rápidos é frequentemente necessário. VPS geralmente não permitem saber o que você tem aqui. Se você disser "disco de 169 gb", a pergunta é: qual orçamento de IO você tem aqui? Se isso é um pequeno disco virtual simples em um disco simples, ou raid 5 ... compartilhado ... barato ... bem-vindo a atrasar IO. se é em discos rápidos, ataque 10 .... isso eu um problema. Além disso, em um tamanho como esse, seu servidor é muito "incomum", pois é pequeno. Banco de dados de 10GB eu iria manter tudo na memória (12-16gb de memória do servidor apenas para o servidor db). e 6 núcleos e 7GB é um pouco estranho (pouca memória para muitos núcleos).

Para otimizar, você pode:

• Analise as instruções SQL, especialmente aquelas que levam tempo e fazem muito IO. Não sei como obter essa informação do MySQL (eu faço principalmente sql server). mabe há algum índice faltando? 9 milhões (!) Posts não são o que todos os fóruns têm, então você pode encontrar um problema de otimização do banco de dados que não é um problema para a maioria das pessoas.
• Faça verificações de E / S do disco e descubra como o orçamento de IO do disco está ruim.
• Altere suas estatísticas do Mysql. Os buffers que você cita lá são muito pequenos para um banco de dados de 10GB. Por exemplo: tmp_table_size = 16M - se houver necessidade de uma tabela temporária para algo, ela pode muito pequena para um banco de dados de 10GB. Sme com praticamente todos os outros itens - o banco de dados não é 1gb grande, então talvez seja necessário algum ajuste.

Answer 6

• verifique o link e considere ajustar os tamanhos de cache e as tabelas tmp de acordo com eles
• analise as consultas mais lentas mais acessadas e considere otimizar (ou evitar) as mesmas
• se você estiver usando unidades de disco sata, migre para unidades mais rápidas - por exemplo, SAS ( isso é importante )
• se você estiver usando o raid1 com apenas 2 unidades de disco, tente expandi-lo para 4 no raid10
• se você está limitado pelo orçamento em fazer os dois acima, considere estender a RAM disponível e colocar o banco de dados no ramdisk com replicação para o segundo host com discos rígidos (isso é extremamente arriscado, mas se você puder perder alguns dados recentes em caso de acidente, e não é o núcleo de seus negócios, pode ser uma opção)