Quantas seleções por segundo um servidor mysql pode executar?

19

Estou escrevendo um plano de negócios e preciso simular o custo quando meu site chegar a 500.000 visitantes únicos.

visitantes: 500.000
visualizações de página: 1.500.000
visualizações de página do spider: 500.000
total de visualizações de página: 2.000.000

Cada página faz 50 consultas + -

consultas por dia: 100 milhões
por hora: 4 milhões
por minuto: 70.000
por segundo: 1.200
pico: 3.000

Fazendo esse cálculo, preciso de 3.000 consultas em segundo ... que tipo de servidor pode lidar com isso?

O problema é: na verdade, meu site está fazendo 2.000 visitas por dia e tendo - + 150/200 consultas / segundo ... a partir deste ponto, esperarei 50.000 consultas / segundo.

Quantos servidores eu preciso no cluster ou replicação gerenciam este trabalho?

mysql linux

— Restabelecer Monica
fonte

5

Que tipo de site 8k + consulta uma visita?

— Ignacio Vazquez-Abrams

5

Você precisa de uma revisão do design do sistema imediatamente.

— Chopper3

11

Não há informações suficientes, porque você não nos disse nada sobre o que realmente importa - as próprias consultas. Nem precisa nos contar sobre a máquina que você está executando. Isso é 486? O melhor e mais recente supercomputador ou algo assim? Todos esses números que você listou são irrelevantes para a pergunta. Por favor, forneça informações RELEVANTES.

— John Gardeniers

> Que tipo de site 8k + consulta uma visita? recebo 2000 visitantes únicos, mas cada visitante abre muitas páginas, + tenho muitas aranhas dentro. 2000 usuários únicos estão gerando 6000 ips exclusivos, abrindo mais de 120.000 páginas abertas diariamente. graças

22

Eu trabalhava para uma empresa de comércio eletrônico com um site que tinha vários milhões de visitas por página por dia. Tivemos um único DELL PE 1750 com 2 CPUs de núcleo único e 2 GB de RAM, tamanho do banco de dados aprox. 4GB. Nos horários de pico, esse servidor processava mais de 50 mil consultas por segundo.

Dito isto: o banco de dados foi bem estruturado, todas as consultas foram ajustadas com precisão (tivemos sessões semanais analisando os logs de consultas lentos e corrigindo consultas e índices) e a configuração do servidor também foi ajustada. O armazenamento em cache é definitivamente uma boa idéia, mas o MySQL faz isso de qualquer maneira, basta analisar o desempenho e ajustar como a memória é usada (cache de consulta versus outras opções).

A partir dessa experiência, posso dizer que o maior impacto é causado por índices ausentes, índices incorretos e design incorreto do banco de dados (por exemplo, campos de cadeia longa como chaves primárias e absurdos semelhantes).

— wolfgangsz
fonte

8

Tudo depende da complexidade da consulta, da quantidade de memória que os servidores possuem e da rapidez com que os discos são.

Se as consultas forem muito simples ou muito bem ajustadas, um único servidor de banco de dados grande poderá lidar com isso. Se, no entanto, as consultas forem muito complexas (ou simples, mas mal ajustadas), você precisará de vários servidores.

— Mrdenny
fonte

Ou algumas alterações de esquema graves e reindexação ...

— Massimo

3

O ajuste é SEMPRE preferido, em vez de adicionar mais hardware. A adição de mais hardware apenas oculta o problema até que o problema seja muito mais difícil de resolver.

— Mrdenny

Obrigado pela resposta, então eu acho que 2 servidores em paralelo + 1 passivo por redundância devem estar ok, certo? Estou falando de servidores 2x núcleos quad com 32 g de ram e unidades rápidas. Estou certo? lembre-se que eu preciso de performances!

11

tudo está bem ajustado e indexado, tenho 1 ou 2 consultas lentas por semana (e o tempo de consulta lento é de apenas 2 segundos) de qualquer maneira, estou escrevendo um plano de negócios e gostaria de saber que tipo de pool de servidores pode gerenciar 12.000.000 páginas abertas de geração diária com 8.000 consultas / segundo

8000 consultas por segundo não são tanto assim. Um único servidor de 16 núcleos provavelmente fará o truque. 64 Gigs de RAM (ou mais ou menos, dependendo do tamanho do banco de dados e da quantidade de dados que precisam ser mantidos no cache a qualquer momento) devem fazer o truque. Meu banco de dados (concedido ao SQL Server) é de 1 TB em um servidor de 16 GB e 64 GB de RAM, com 40 a 50 mil usuários acessando-o diariamente até várias vezes por minuto (cada) durante o dia.

— mrdenny

3

Isso realmente não pode ser estimado sem saber nada sobre as consultas específicas que você está executando, o esquema do banco de dados e seu tamanho.

Um SELECT simples em uma coluna indexada é um animal completamente diferente de um par de JOINs baseados em não indexados ... e é claro que as coisas mudam muito se as tabelas envolvidas contiverem 1K registros ou 1M.

Além disso:

Qual é a sua configuração de hardware atual?
Quanto de sua energia (CPU, RAM, E / S de disco) está sendo usada pelo servidor sob a carga atual?

— Massimo
fonte

Na verdade, eu tenho um servidor com 2x quad core com 8 GB de RAM. estou usando a ram completa e 100% do processador (parece que posso usar 800%, veja aqui :) cpu: img834.imageshack.us/img834/3483/downloadv.png ram: img442.imageshack.us/i/ disco do download2p.png : img213.imageshack.us/i/download1x.png obrigado

Com base nesses gráficos, você está usando apenas um (ou no máximo dois) de seus núcleos de CPU; portanto, seu aplicativo definitivamente não é vinculado à CPU ... ou é, mas é incapaz de tirar proveito de várias CPUs. Além disso, toda a memória usada para o "cache" não é realmente necessária por ninguém, é apenas o sistema operacional que aproveita porque "está lá".

— Massimo

Como posso encontrar informações sobre o uso de todos os núcleos da CPU? Estou usando lâmpada ...

Antes de tudo, verifique se você não os está usando, porque simplesmente não há necessidade deles (= carga baixa), porque suas operações não podem ser adequadamente paralelizadas ou porque seu MySQL e / ou Apache não estão configurados para usa-os. E, como esses dois programas geralmente são multithread por padrão, eu daria uma olhada na carga do servidor e nas consultas SQL ...

— Massimo

3

Como Ignacio observou, você pode querer examinar o cache. No cms ou talvez até na frente da pilha. Mais de 50 consultas para cada página (a cada!) Realmente são muitas.

— Joris
fonte

sim, este é um site complexo, é uma comunidade, não consigo armazenar nada em cache, está mudando a cada segundo. Tentei armazenar em cache as páginas, mas o hitrate do cache era quase 0, pois toda vez que coloco em cache uma página, ela nunca pode ser lida novamente ou pode ser alterada antes de ser aberta novamente. obrigado

4

Existem muito poucos sites inacessíveis; se ele mudar apenas a cada segundo, você ainda pode armazenar em cache por um segundo inteiro, como 10 visualizações de página ;-) Você considerou não armazenar páginas em cache por inteiro, mas bloqueia ou valores específicos, etc.? Você pode armazenar em cache fora do banco de dados, em segmentos de memória compartilhada, sistema de arquivos e cache de memórias. Além disso, tipicamente em uma tal situação pode ser útil ESI

— Joris

0

A julgar pelos seus comentários, o maior fator será o tamanho do seu conjunto de dados ou pelo menos o tamanho do conjunto de dados "quente". 3.000qps ou mesmo 8.000qps em um servidor de 16 núcleos não é um problema, desde que o servidor raramente precise ir ao disco para satisfazer a consulta. Quando o conjunto de dados ativos exceder a quantidade de memória que o InnoDB está usando para armazená-lo em cache, seu desempenho será reduzido rapidamente.

— Elliott
fonte

0

Para grandes conjuntos de dados "quentes", provavelmente vale a pena investir tempo para converter em um esquema de "big data"; é para isso que servem. Por exemplo, se você possui uma grande quantidade de dados para recuperar, mas nunca reescreve, mas apenas acrescenta novos dados, consulte o Apache Hive. Navegue ao redor, geralmente é um sabor que você pode interagir facilmente com o código existente, o que também impedirá a azia de ficar sem espaço em cache.

— BHGalyean
fonte

0

Existem muitas coisas que podem afetar suas consultas por segundo. Não confie nos meus dados sem testar a si mesmo. Publico aqui o resultado do teste de velocidade para ajudar alguém a estimar o qps com o banco de dados e a máquina mysql atuais (2018-09). No meu teste, o tamanho dos dados é menor que a memória do servidor (que reduz drasticamente a IO e melhora muito o desempenho).

Eu uso uma instância de um CPU cpu 3.75GB de memória, 100GB ssd, gcp cloud mysql server e obtenho:

1 cliente, um sql e uma linha lida: 799 sql / segundo.
50 clientes, um sql em uma linha lida: 6403 sql / segundo.
50 clientes, uma gravação sql de uma linha: 4341 linhas gravadas, qps. 4341 sql / segundo.
1 cliente, gravação de 30k linhas por sql: 92109 linhas / s gravadas.

— homem de bronze
fonte

write qps test result (2018-11) gcp mysql 2cpu 7.5GB memória 150GB serialização ssd escreve 10 threads, gravação de 30k linhas por sql, tabela 7.0566GB, o comprimento da chave de dados é 45 bytes e o valor é 9 bytes, obtenha 154KB linhas escritas por segundo, a CPU 97,1% grava qps 1406 / s no console gcp.

— bronze man