[MASOCH-L] Mysql
Marcos Dutra
macdutra at gmail.com
Mon Oct 29 17:46:06 BRST 2007
Olá Leonardo, eu li sua mensagem e realmente tem mais outras tabelas pesadas
desse nível, mas só gostaria de dizer que tem duas tabelas com 1,3GB que é o
histórico da empresa de anos anteriores só para pesquisa de relatórios que é
usado esporádicamente, e tabelas desse ano de 2007 que é usada pela empresa
toda todos os dias tem em média 800 MB, antes de mudar esse máquina era
usando duas máquinas com 1GB de ram cada uma para essas tabelas 1,3GB de ram
e outra para o uso diário e ainda sincronizando o banco de dados com o mysql
esquisito não?
Abraços
Marcos
On 10/29/07, Marcos Dutra <macdutra at gmail.com> wrote:
>
> Pessoal fui fazer os testes com o with(nolock) como sugeriram mas acho que
> não funciona, pelo menos para mim que tem o Mysql 5.0.45 usando o MYISAM
> retorna o erro:
> select * from usuarios WITH(NOLOCK) where descricao like "%a%"
> You have an error in your SQL syntax; check the manual that corresponds to
> your MySQL server version for the right syntax to use near 'WITH(NOLOCK)
> where descricao like "%a%"' at line 1
>
> Respondendo aos amigos da lista para usar outro banco de dados que não
> seja o mysql, nesse caso teríamos que mudar toda a base de dados e além
> disso todos os programas que estão feitos desde 2000, então essa migração
> ficaria para planos futuros, mas não nesse momento.
>
> Obrigado
> Marcos
>
> On 10/29/07, Fabiano <fabiano.br at uol.com.br> wrote:
> >
> >
> > Bom dia,
> >
> > Reconheço que não li os "300 posts com
> > Mysql", porém, quero fazer um questionamento a quem iniciou ...
> > Antes de atacar somente o físico
> > (substituindo,etc) e vi que saíram soluções muito
> > boas,porém ,você testou o comportamento com
> > outros bancos como PostgreSql ou Oracle ?
> > Pergunto porque em um projeto
> > específico, onde o número de consultas era alto,
> > chegou ao ponto em que substituímos o Mysql por
> > Postgresql por questões de desempenho e
> > estabilidade (já tem alguns anos). Detalhe :
> > neste projeto havia uma *superbase* num Oracle, e
> > bases "satélites" em pequenas máquinas para
> > algumas leituras especializadas de algumas
> > tabelas bem específicas e obviamente, sincronização entre as bases...
> > Para nós ... solucionou.
> >
> > Att,
> > Fabiano
> >
> >
> > At 20:44 28/10/2007, Antonio Carlos Pina wrote:
> > > A documentação do treco diz que a bateria é recarregável e que só
> > duraria
> > >15 horas mesmo. Eu chutaria que ele, como empresa que funciona no
> > horário
> > >comercial, poderia copiar a tabela para o disco RAM, trabalhar com ele
> > no
> > >disco RAM no decorrer do dia e depois copiar para o disco físico. Ou
> > ter
> > >momentos de dump para o disco rígido para esses casos de mais de 15
> > horas
> > >sem energia.
> > >
> > >Sobre o uso de memória pelo linux...A ineficiência que vejo não é nem o
> > uso
> > >de memória e sim a quantidade de iops que a operação vai demandar + o
> > espaço
> > >limitado para carga de cache de disco. Para acreditar que a tabela
> > estará
> > >inteira na memória, precisaríamos otimizar o SO para fazer um prefetch
> > da
> > >tabela inteira, sem que isso se misture com o cache de disco (já que
> > outras
> > >operações estarão em curso e o linux terá de descarregar páginas em
> > algum
> > >momento).
> > >
> > >A idéia do solid state é muito boa, mas há dois pontos a serem
> > considerados:
> > >Velocidade de acesso e custo.
> > >
> > >Abs
> > >
> > >
> > >Em 28/10/07, Leonardo Rodrigues Magalhães <leolistas at solutti.com.br>
> > >escreveu:
> > > >
> > > >
> > > > (redação ... desculpa gente, não briguem comigo :) )
> > > >
> > > > Esse produto ai eu não conhecia ... ele pega pentes convencionais
> > de
> > > > memória RAM e 'converte' eles em disco. Interessante ... mas vamos
> > > > analisar.
> > > >
> > > > O uso de informações em algum tipo de memória volátil é muito
> > > > perigoso. Leia o anúncio onde a pessoa explica que a bateria segura
> > a
> > > > informação por 15 horas. E se faltar energia no final de semana
> > inteiro
> > > > ??? lá se foram seus dados pro espaço. Claro que é uma situação
> > extrema
> > > > .... mas não podemos desconsiderá-la.
> > > >
> > > > Talvez valesse a pena utilizar SSDs (Solid State Disk) de
> > verdade,
> > > > que utilizam memória eletrônica porém não-voláteis, os famosos HDs
> > Flash
> > > > que estão começando a ser utilizados em notebooks top de linha.
> > Exemplo:
> > > >
> > > >
> > > >
> > >
> > http://cgi.ebay.com/32GB-Solid-State-Disk-SSD-2-5-SATA-Laptop-Hard-Drive_W0QQitemZ320173041357QQihZ011QQcategoryZ116342QQssPageNameZWDVWQQrdZ1QQcmdZViewItem
> > > >
> > > > Pena que nunca vi pra vender no Brasil. E se alguém tiver, o
> > preço
> > > > vai ser altíssimo. 400 dólares nos Estados Unidos, vai chegar aqui
> > no
> > > > Brasil, legal com NF e tudo, na casa dos 2000 reais.
> > > >
> > > > Aliás, nunca tinha visto preço desses novos SSDs ... 400 dólares
> > nos
> > > > Estados Unidos pra 32Gb ... mesmo que chegue aqui por 2000-2500,
> > ainda
> > > > assim está MUITO mais em conta que essa placa ai que você apontou do
> > > > Mercado Livre. 1050 reais por 4Gb (R$ 262,5/Gb), se conseguirmos
> > 2500
> > > > reais em 32Gb teremos R$ 78,13/Gb.
> > > >
> > > > Agora ainda assim, vamos desconsiderar preço, eu ainda acho que é
> > > > uma solução que mereçe pelo menos alguma pensada, já que não
> > trata-se de
> > > > uma solução mágica.
> > > >
> > > > É claro que a utilização de um disco 'eletrônico' vai reduzir a
> > > > quase zero os seek times e a leitura dos dados do disco pro kernel
> > vai
> > > > ser quase instantânea. Mas isso por si só não tira o fato de que o
> > MySQL
> > > > vai ter que 'processar' 1,3Gb (ou mais) de dados pra processar cada
> > > > query do sistema dele que tenha que varrer a tabela inteira. A gente
> >
> > > > melhora ao nível quase máximo a taxa de transferência entre
> > dispositivo
> > > > de I/O e kernel, mas ainda existe o processamento da tabela inteira.
> > > > Pode ser que reduza pela metade, pode ser que reduza 3/4 ... mas
> > numa
> > > > tabela desse tamanho, o tempo de processamento nunca vai ser 1-2
> > > > segundos, mesmo que a informação venha de uma mídia eletrônica.
> > > >
> > > > Mesmo que a leitura seja mais rápida, ainda vamos ter o problema
> > dos
> > > > locks. Claro que leitura mais rápida, tabela menos tempo bloqueada.
> > Mas
> > > > o problema continua existindo.
> > > >
> > > > E por último, não podemos esquecer que o Linux utiliza muito
> > > > sabiamente a memória RAM da máquina. Se a memória não está alocada,
> > vai
> > > > tudo pra cache e buffers de gravação de disco. A máquina em questão
> > tem
> > > > bastante memória (4Gb). Se ela não tiver outras tabelas grandonas,
> > essa
> > > > de 1,3Gb for a única tabela 'pesada', então muito provavelmente
> > grande
> > > > parte dela já está alocada em memória RAM, através dos caches e
> > buffers
> > > > de I/O que o Linux automaticamente faz. Na primeira passada depois
> > de um
> > > > reboot, aí sim a leitura vai acontecer direto do disco. Mas nas
> > > > próximas, muita coisa já virá de memória RAM. É assim
> > automaticamente.
> > > >
> > > > Agora se o cara tiver várias tabelas enormes e/ou tiver algum
> > outro
> > > > sistema que aloque bastante memória, talvez não sobre tanta memória
> > > > assim pra caches e buffers. Seria legal que o criador ai da thread
> > nos
> > > > disesse se essa tabela de 1,3Gb é basicamente a única pesadona ou se
> > ele
> > > > contém várias tabelas nesse nível de tamanho. Melhor ainda seria se
> > ele
> > > > falasse pra gente qual o tamanho inteiro do database dele !! Se o
> > > > database inteiro tem 2Gb, com a máquina de 4Gb, em pouco tempo após
> > o
> > > > reboot a grande maioria das tabelas estarão em buffers e cache,
> > > > reduzindo bastante (e de forma automática) o I/O em disco.
> > > >
> > > > Usar um disco RAM ou SSD vai melhorar a situação dele ?? Acredito
> >
> > > > que sim. É substituir e melhorar. Agora resta saber se a melhora vai
> > ser
> > > > suficiente para que o sistema volte a ficar plenamente utilizável de
> > > > novo. Não adianta nada melhorar, você conseguir mensurar que
> > melhorou,
> > > > porém ainda assim o sistema ficar lentão. Não importa quantos
> > segundos a
> > > > query leva pra executar. Importa é a percepção de rapidez do sistema
> > que
> > > > o usuário tem.
> > > >
> > > > Dito tudo isso e sabendo que o Linux utiliza muito sabiamente a
> > > > memória RAM que está sobrando, talvez seja uma solução mais rápida e
> > > > imediata simplesmente aumentar ainda mais a memória RAM do servidor,
> > já
> > > > que esse aumento gerará, automaticamente e sem fazer absolutamente
> > nada
> > > > de configuração, com que as tabelas vão para memória RAM através de
> > > > caches e buffers.
> > > >
> > > > Será que a máquina dele suporta mais de 4Gb ??? SIM
> > > >
> > > >
> > > >
> > > http://www.dell.com/content/products/productdetails.aspx/pedge_2950?c=us&cs=04&l=en&s=bsd&~section=specs#tabtop
> >
> > <http://www.dell.com/content/products/productdetails.aspx/pedge_2950?c=us&cs=04&l=en&s=bsd&%7Esection=specs#tabtop>
> > > >
> > > > PowerEdge 2950 Server Specs
> > > > Up to 32GB (8 DIMM slots): 256MB/512MB/1GB/2GB/4GB Fully Buffered
> > Dimms
> > > > (FBD). 533/667MHz
> > > >
> > > >
> > > >
> > > >
> > > > Antonio Carlos Pina escreveu:
> > > > > Depois que tanta gente escreveu tanta coisa legal, eu vou dar meu
> > pitaco
> > > > > mais voltado para a solução do problema de forma rápida.
> > > > >
> > > > > Considerando que você tenha um problema de modelagem de BD ou de
> > > > programação
> > > > > (os citados select * from recorrentes, por exemplo, em cada página
> > que
> > > > vc
> > > > > entra lá vem um select * from..) talvez você precise de uma
> > solução
> > > > RÁPIDA
> > > > > enquanto resolve isso (reescrever código, banco, etc)
> > > > >
> > > > > DEPENDENDO do tamanho das suas tabelas e da velocidade que elas
> > crescem,
> > > > > isso aqui pode ser uma solução:
> > > > >
> > > > > http://produto.mercadolivre.com.br/MLB-63419971-_JM
> > > > >
> > > > > É um "disco ram" acessível através de uma interface SATA. Esse
> > possui
> > > > 4Gb e
> > > > > custa, no mercado livre, R$ 1050,00. Ou seja, muito mais barato
> > que
> > > > > reescrever sua aplicação (preste só atenção no crescimento do
> > banco, por
> > > > > favor !)
> > > > >
> > > > > Você poderia copiar para ele suas maiores tabelas (como essa
> > > > problemática de
> > > > > 1,3Gb) e o problema de acesso estaria resolvido, até que você
> > pudesse
> > > > > trabalhar nas alterações de código e remodelagem do banco.
> > > > >
> > > > > Detalhe importante: Li sobre esse troço na Internet. Eu mesmo
> > nunca
> > > > usei. Na
> > > > > teoria, seria facílimo mover a(s) tabela(s) para dentro desse
> > disco e
> > > > criar
> > > > > links no SO para elas.
> > > > >
> > > > > Abs e boa sorte!
> > > > >
> > > >
> > > > --
> > > >
> > > >
> > > > Atenciosamente / Sincerily,
> > > > Leonardo Rodrigues
> > > > Solutti Tecnologia
> > > > http://www.solutti.com.br
> > > >
> > > > Minha armadilha de SPAM, NÃO mandem email
> > > > gertrudes at solutti.com.br
> > > > My SPAMTRAP, do not email it
> > > >
> > > >
> > > >
> > > >
> > > > __
> > > > masoch-l list
> > > > https://eng.registro.br/mailman/listinfo/masoch-l
> > > >
> > >__
> > >masoch-l list
> > > https://eng.registro.br/mailman/listinfo/masoch-l
> >
> > __
> > masoch-l list
> > https://eng.registro.br/mailman/listinfo/masoch-l
> >
>
>
More information about the masoch-l
mailing list