[MASOCH-L] Mysql

Mon Oct 29 17:37:26 BRST 2007

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
> > >
> > > 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
>