[MASOCH-L] Mysql

Mon Oct 29 11:05:41 BRST 2007

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