[MASOCH-L] Mysql

Sun Oct 28 20:03:27 -03 2007

    (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