Excelente post, vou postar uma experiência…
Consegui reduzir drasticamente o tempo de execução de algumas consultas no MySQL, após aprender usar corretamente os índices. A diferença foi gritante, passou de vários minutos para alguns segundos!
No meu caso, principalmente o uso de índices em campos que são muito usados em cláusulas WHERE, fez muita diferença.
bom dia Santos,
poderia dar exemplos ou fazer um vídeo para ter uma noção melhor
um abraço e feliz 2013
Nigri
Com a correria aqui fica um pouco complicado, mas não tem muito segredo, abaixo algum material que fala um pouco a respeito:
Links
http://falandoti.com.br/dica-rapida-usar-index-no-mysql-nos-campos-de-pesquisa/
http://www.linhadecodigo.com.br/artigo/3620/indices-mysql-otimizacao-de-consultas.aspx
http://www.webgoal.com.br/como-otimizar-consultas-no-mysql/
http://www.webmaster.pt/mysql-otimizacao-indices-5148.html
Video
http://www.homehost.com.br/blog/como-otimizar-um-banco-mysql-usando-indices/
Bom dia,
Fiz testes com postgresql, mysql e firebird em uma base que tem uma tabela com 1Gb de dados.
Segue alerta de desempenho do scriptcase com Firebird e postgresql.
Em formulários e grids o scriptcase para fazer a paginação usa um select count() from tabela tal.
Para usuário do mysql isto nem faz cosquinhas.
Mas o tipo de versionamento do postgresql e firebird tornam o uso do count() lento.
Ver:
http://wiki.postgresql.org/wiki/Slow_Counting
http://www.firebirdfaq.org/faq5/
Então sempre use o where em seus selects nestes SGDBS com o scriptcase, nunca use um select * from xxxx.
Acredite! Tem gente que ainda faz o select * from como se fosse a coisa mais normal do mundo.
Com muitos registros é um desastre.
No firebird e postgresql na tabela de 1gb o count(*) chegava a demorar 43 segundos. Para depois executar a query em menos de 1 segundo.
No mysql tudo era executado em menos de 1 segundo no myisam e de alguns microsegundos a 3 segundos no innodb
Aproveito para lembrar que isto não é uma situação onde se deva considerar o mysql ótimo para tudo.
Lembro que o mysql é sempre rápido para consultas.
Mas em testes de desempenho para insert ou update com volume alto de transações ele costuma se sair pior que o firebird e o postgresql.
Além do que ele não trabalha com tabelas com campos blob e text em memória e sim sempre em disco.
E etc, etc, etc
De qualquer forma o melhor banco para trabalhar é aquele que você conhece e sabe suas fraquezas, forças, como otimizá-lo e em que situação aplicá-lo.
Para os novatos aconselho também a não utilizar mais de três selects com lookup num form.
Não importa qual seja o SGDB usado, mais de três selects com lookup em base de dados é uma lentidão.
Ótimo tópico. Muita gente esta fazendo seus sistemas sem uma base que é fundamental, o banco de dados. Relacionamento de tabelas, seus index, FK, joins, etc… são fundamentais para um bom desempenho do sistema.
Parabéns pela iniciativa Alexandre, és um grande profissional.
Abraços!
Pessoal sei que o tópico é velho.
Mas posto aqui o conteúdo de um script que deixo no cron do Linux.
Mas pode ser adaptado para o windows.
Façam backup sempre antes de usar este script.
E não me responsabilizo se algo der errado. Posto porque o manual do mysql diz que é bom fazer. E porque me ajuda bastante a manter a performance do servidor.
Ele irá reparar tabelas corrompidas.
Otimizar tabelas e analisar.
Segue conteúdo do script.
#!/bin/bash
date
mysqlcheck --repair --all-databases -v -uroot -psuasenha
mysqlcheck --optimize --all-databases -v -uroot -psuasenha
mysqlcheck --analyze --all-databases -v -uroot -psuasenha
mysqlcheck --all-databases -m -v -uroot -psuasenha
mysqlcheck --all-databases --auto-repair -v -uroot -psuasenha
date
Explicação da diferença entre analyze e optimize :
OPTIMIZE TABLE (http://dev.mysql.com/doc/refman/5.5/en/optimize-table.html) -> Reorganiza o armazenamento físico dos dados da tabela e dados de índice associados, para reduzir o espaço de armazenamento e melhorar a eficiência de I/O ao acessar a tabela. As alterações exatas feitas para cada quadro dependem do mecanismo de armazenamento usado por essa tabela.
ANALYZE TABLE (http://dev.mysql.com/doc/refman/5.5/en/analyze-table.html) -> analisa e armazena a distribuição de chaves para uma tabela. Durante a análise, a tabela é bloqueada com uma trava de leitura para InnoDB e MyISAM. Esta declaração funciona com o InnoDB, NDB e tabelas MyISAM. Para tabelas MyISAM, esta declaração é equivalente a usar myisamchk - analyze.
O MySQL utiliza a distribuição de chaves armazenadas para decidir a ordem em que as tabelas devem ser unidas quando você executar um join em alguma coisa diferente de uma constante. Além disso, a distribuição das chaves pode ser usado no momento de decidir quais índices usar para uma tabela específica em uma consulta.
O script pode ser usado de 1 vez por semana a 1 vez por mês.
Aqui como tenho bancos maiores que 9gb uso duas vezes por semana.
Como há o travamento das tabelas sempre aconselho a rodar de madrugada
Seguem três documentos comparando Mysql, Firebird, Postgresql e SQL server.
Um deles é trabalho de bacharelado e outros dois TCC.
http://www.faculdadeexpoente.edu.br/upload/noticiasarquivos/1278624761.PDF
http://www.firebase.com.br/fb/imgdocs/tcc_fbmysql.pdf
Este último feito com versões mais recentes do quatro bancos.
http://www.unipac.br/bb/tcc/tcc-15ee06c022b6b866f2815b76757c667f.pdf
Aprendi uma coisa com o Alexandre ao longo do tempo:
Nunca pergunte nada pra ele e espere uma resposta simples. Rsrs.
Sempre será uma aula. Uma baita aula.
Obrigado, Alexandre.
Fantástico!
Obrigado a todos.
[size=18pt]Atenção!!![/size]
O mysql 5.6 à partir da versão 5.6.9 está com um bug onde há um alto consumo de memória.
Conforme seu hardware e configurações (my.cnf, my.ini) ele irá travar seu servidor ou causar lentidão.
Vide: http://www.chriscalender.com/?p=1278
http://bugs.mysql.com/bug.php?id=68287
[size=18pt]
Instalador do scriptcase em ambiente de produção provoca paradas (travamentos) no apache.[/size]
Sim eu sei que no seu servidor está tudo ok!
Mas cada servidor é um caso.
Está dica vai para quem usou o instalador e o apache tem que ficar sendo restartado.
Considere que o apache do instalador é otimizado para rodar o scriptcase com um pequeno número de desenvolvedores em cima.
Alguns clientes meus onde o acesso ao servidor é em produção e fizeram uso do instalador.
O alto número de acessos concorrentes provoca a queda do servidor apache.
A solução é mexer nas configurações do apache e do zend fazendo um tuning.
Detalhe: se deixar o php como cgi ele irá consumir bastante memória.
Depois do tuning o apache passou a funcionar normal.
Pois é, ontem ele deu 3 travadas e só re-iniciando o apache que voltava ao normal. Pensei ser meu loop while que estava louco, mas não! Dependendo da aplicação (se requer muita memória) ele trava na execução do mesmo.
Vou estudar como fazer esse tuning no apache e no zend.
Obrigado Alexandre!
Dica
Para acompanhar o desempenho do seu servidor! Zabbix nele!
http://www.zabbix.com/
Detalhe para windows instale o unixtools e no agent coloque:
Obs: Este editor não aceita colchete com asterisco, logo onde se lê (colchete) substitua.
UserParameter=mysql.status(abre colchete)*(fecha colchete),mysql -uusuariodobanco -ANe “show global status where Variable_name=’$1’” | cut -f2
UserParameter=mysql.ping,mysqladmin -uusuariodobanco ping | grep alive | wc -l | cut -d" " -f 7
UserParameter=mysql.uptime,mysqladmin -uusuariodobanco status | cut -d: -f2 | cut -d " " -f2
UserParameter=mysql.threads,mysqladmin -uusuariodobanco status | cut -d: -f3 | cut -d " " -f2
UserParameter=mysql.questions,mysqladmin -uusuariodobanco status | cut -d: -f4 | cut -d " " -f2
UserParameter=mysql.slowqueries,mysqladmin -uusuariodobanco status | cut -d: -f5 | cut -d " " -f2
UserParameter=mysql.version,mysql -V
[size=14pt]Obs: façam backup antes dos procedimentos não me responsabilizo por perdas de dados.[/size]
[size=12pt]
Se seu scriptcase desenvolvimento estiver lento e não é mais o mesmo. Pode ser fragmentação no banco de dados em que ele foi instalado.[/size]
Para instalação no mysql ler neste post: http://www.scriptcase.com.br/forum/index.php/topic,5689.msg39937.html#msg39937
Comando disponiveis no phpmyadmin e sql.
Para instalação no sqlite use o comando vacuum nas tabelas e indexes. http://www.sqlite.org/lang_vacuum.html
No sqliteadmin use o icone limpar database.
Ou use no sql
Para o postgresql use reindexdb, vacuumdb e analyze -> http://www.postgresql.org/docs/9.3/static/app-reindexdb.html , http://www.postgresql.org/docs/9.3/static/app-vacuumdb.html e http://www.postgresql.org/docs/9.3/static/sql-analyze.html
Comandos disponíveis no phppgadmin, pgadmin ou sql
E fim.
[size=14pt]Para se pensar:[/size]
Windows server 2012 requisitos (http://technet.microsoft.com/pt-br/library/jj134246.aspx):
Mínimo: processador de 1,4 GHz e 64 bits
RAM: Mínimo: 512 MB
Espaço em disco: Mínimo: 32 GB
Ou seja isto é o mínimo para ele rodar bem lentium.
Ai façamos a conta:
512 MB do mínimo para ele rodar mais uma margem de 512M para processos dos sistema operacional.
Total 1gb de memória
1GB somente para o windows rodar lentium.
Apache + php + sc (fonte google e experimentações pessoais)
Vamos desprezar o consumo de memória pelo apache e considerar somente pelo php.
Cada chamada do php como php-cgi para rodar o scriptcase pode consumir até 65Mb ou mais um pouquinho.
Obs: o sc instalador instala o php como php-cgi no apache.
Então vamos usar o php como módulo que consome menos memória e supor na melhor das hipóteses que cada chamada consuma 35Mb.
Logo se coloco no apache um limite para 150 conexões temos:
150x35Mb=5250Mb que é aproximadamente 5GB.
Então na pior das hipóteses se 150 usuários acessarem seu servidor simultaneamente temos um consumo de 5Gb de memória.
Ainda bem que isto é difícil de acontecer. Será?
Banco de dados
Vamos pegar o campeão de popularidade: Mysql.
Vamos desconsiderar que campos blob requerem 3x mais memória, para que você vai querer usar campo blob não é mesmo?.
Os mais afoitos podem usar estes sites para calcular o consumo de memória do mysql com base na configuração do my.cnf ou my.ini
http://www.mysqlcalculator.com/
http://www.omh.cc/mycnf/
vamos pegar um caso leve com a pior configuração para seu mysql que tem 2gb de base de dados innodb começar a ficar lentium:
key_buffer_size 64 MB
query_cache_size 64 MB
tmp_table_size 32 MB
innodb_buffer_pool_size 8 MB
innodb_additional_mem_pool_size 1 MB
innodb_log_buffer_size 1 MB
max_connections 150
sort_buffer_size 2 MB
read_buffer_size 128 KB
read_rnd_buffer_size 256 KB
join_buffer_size 128 KB
thread_stack 196 KB
binlog_cache_size 0 MB
Total: 576.2 MB de memória consumida com 150 conexões simultâneas.
Agora vamos ver o MS SQLSERVER. fonte: http://msdn.microsoft.com/pt-br/library/ms143506.aspx
memória Mínima:
Edições Express: 512 MB
Todas as outras edições: 1 GB
Recomendado:
Edições Express: 1 GB
Todas as outras edições: pelo menos 4 GB e deve ser aumentado à medida que o banco de dados cresce para garantir um ótimo desempenho.
Logo para o windows + apache + php + mysql
sistema operacional: 1gb
apache + php 150 conexões: 5gb
mysql 150 conexões simultâneas: 576 Mb
memória mínima que o cloud deve ter: aproximadamente 6.5gb
obs: Isto para ele trabalhar lentium, arrastando e travando na pior das hipóteses.
Para windows + apache + php + ms sqlsever edition express ( a que consome menos).
sistema operacional: 1gb
apache + php 150 conexões: 5gb
Edições Express: 1GB (recomendado)
Memória mínima que o cloud deve ter: aproximadamente 7gb
obs: Isto para ele trabalhar lentium, arrastando e travando na pior das hipóteses.
Obs: quando você considerar o mínimo requerido. Lembre-se que o mínimo do windows seven ultimate para rodar (http://windows.microsoft.com/pt-br/windows7/products/system-requirements) é 1 gigabyte (GB) de RAM (32 bits) ou 2 GB de RAM (64 bits) .
Agora experimente rodar o windows seven ultimate com office, antivirus instalado e 1gb de memória!? Fica uma carroça dependendo da máquina!
E clique hoje, vá tomar um café e volte amanhã.
Logo, imagine o que os requerimentos mínimos de hardware fazem ao ms sqlserver, mysql, php, apache e windows server?
Isto pode ser aplicado ao Linux (http://www.debian.org/releases/wheezy/mipsel/ch03s04.html.pt) e outros sistemas operacionais, também a outros sgdb´s.
Ai você vem me dizer que quando contratou o cloud, montou seu servidor e etc…
E era somente você a usar. Uau!!!.. O “acesso era legal”, mais que demais!
Somente que agora não entende…!? Depois de começar a colocar seus clientes tudo começou a ficar lento.
Seu servidor com: 2Ghz e 2 cores, 2 Gb de memória e 50 Gb de espaço em disco não era para dar conta do recado?
Olha! Se você tiver muita sorte como a maioria tem! E eu sou um dos sortudos.
Os acesso não serão simultâneos e o seu servidor vai dar conta.
Mas sempre terá que fazer uma mágica na configuração. E isto a qualquer hora.
Afinal os perfis de acesso não são fixos. Mas as limitações do seu servidor sim.
Esta mágica de controlar o consumo de memória, disco, processamento tem que ser feita até que você ou eu criemos juízo e coloquemos a mão no bolso.
Espero ter contribuído com a dúvida de muita gente.
Alexandre,
Parabéns pelos posts.
Na instalação default do SC 7 onde fica a base de dados?
O meu está muito lento é quero ver se resolvo utilizando uma das suas dicas.
Obrigado
George obrigado
A instalação padrão fica:
pasta instalação scritpcase\devel\conf\scriptcase\nm_scriptcase.db.
Mas copie esta base para um lugar seguro antes de fazer o procedimento.
Alexandre vc é o cara.
Meu SC voltou a funcionar com a velocidade normal, estava muito lento.
Obrigado
de nada
Olá pessoal,
Relato caso acontecido com nosso amigo aqui do fórum.
Problema relatado: lentidão no sc 7.1 com php 5.4.
Teste feito com sc IDE instalado com mysql e sqlite e ficava lento nos dois.
Executado vaccum no sqlite e ainda continuava lento.
Solução:
Nos teste desabilitamos o antivírus e o sc voltou a funcionar normal.
O firewall do antivírus estava deixando lento o SC.
Antivírus: Mcafee Live Safe 12.8 para windows 8.1
Dica
Quando o SC estiver lento e a desfragmentação ou tuning do apache + SGDB não funcionar experimente desligar o antivírus.
Ele pode ser o grande vilão no que diz respeito do desempenho do SC IDE.