[MASOCH-L] Mysql

Sun Oct 28 21:44:12 BRST 2007

 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
>