Gargalo de Desempenho do MySQL - E / S ou CPU?

Question

Estou desenvolvendo um aplicativo da web e tenho uma grande diferença de desempenho entre a velocidade das pesquisas do MySQL em meus ambientes de desenvolvimento e ao vivo.

BANCO DE DADOS: 2,5 GB, três tabelas (uma tabela tem 27 milhões de registros). Índices FULLTEXT e busca. Tudo é indexado quando necessário. Banco de dados contém registros de todos os endereços no Reino Unido.

DEV SERVER: Dois anos de idade Samsung i5 Ultrabook. Windows 8 executando o XAMPP. SSD único. A maioria das pesquisas leva menos de 200 ms, deliberadamente enfatizando os resultados do sistema em um tempo máximo de pesquisa de 5 segundos.

SERVIDOR AO VIVO: VPS "híbrido" (max 8 nós por servidor). As especificações de hardware são "Dois processadores Intel Xeon com um mínimo de 8 núcleos de CPU, 24 GB de RAM, RAID 10 unidades com unidades SAS de 15 K". A maioria das pesquisas leva de 3 a 5 segundos, com um teste de estresse resultando em pesquisas de 30 segundos.

Estou feliz com o desempenho do banco de dados no meu servidor de desenvolvimento, mas realmente preciso que o servidor de produção corresponda ou melhore isso.

Antes de eu mergulhar em uma caixa dedicada para o aplicativo, na sua experiência, o gargalo provavelmente seria E / S de disco ou tempo de CPU?

Apenas postando uma resposta para o registro:

Eu tentei o aplicativo em um VPS com SSDs RAID-ed. A diferença é noite e dia e as pesquisas agora são ainda mais rápidas do que a minha máquina de desenvolvimento. Isso é com uma instalação padrão do MySQL, sem edições feitas no cache, uso máximo de memória e outros parâmetros.

    

Answer 1

Ignore o MySQL no momento - isso é o mesmo para todos os bancos de dados. A física não se importa com o código aberto.

Geralmente você é IO Limited, a menos que você não seja. O último meio é ter RAM suficiente para armazenar em cache todas as operações de E / S na memória - típicas para grandes cargas de trabalho OLAP. Mas qualquer transação transacional terá o OI como um limite muito antes da CPU, a menos que a CPU seja patética (ou seja, você sempre pode construir um servidor que force a sobrecarga da CPU - os átomos podem ser uma má escolha para servidores de banco de dados).

ow, servidor de produção. SOmeone majorly fez "estúpidos" erros comprando thise.

Raid 10 Drives with 15K SAS drives".

Cerca de 450 IOPS por unidade.

Single SSD

Isso gira em torno de 40.000 a 60.000 IOPS - pode ir até 90.000 dependendo do disco e da carga.

Veja o problema? O SSD está voando em torno dos discos SAS - é um trocador de jogos. SAS é lento. Eu uso um monte de 10k discos SAS no meu banco de dados principal - mas com SSD como camada de cache transparente.

Portanto, a menos que você tenha RAM suficiente para tornar os discos SAS irrelevantes (armazena em cache tudo na memória) e, em seguida, pré-carrega (e isso é possível em seu pequeno banco de dados de apenas 2.5g). p>

No seu caso particular, eu verificaria a configuração. A configuração padrão do MySQL permitirá que o IIRC não use muita memória, independentemente de estar lá. Com um pequeno banco de dados (2.5g) você deve armazenar tudo na memória. Até no laptop. Parece um problema de configuração.