Arnaldo Luiz Estevão (porducel@bol.com.br) nos enviou:
Tive uma idéia que deu certo e esta dando um excelente resultado por isso resolvi compartilhar com a comunidade trata-se de um esquema para instalar um servidor postgresql em ramdrive.
Servidor Postgresql em ramdrive
por Arnaldo Luiz Estevão - porducel@bol.com.br
Tive uma idéia que deu certo e esta dando um excelente resultado por isso resolvi compartilhar com a comunidade trata-se de um esquema para instalar um servidor postgresql em ramdrive.
1 - O objetivo
Aumentar significativamente a performance do sistema sem comprometer a segurança.
2 - Os pacotes
Posgresql
3 - As delimitações
Este projeto foi feito pensando em unico banco de dados para mais de um banco de dados será necessário fazer adaptações.
4 - Garantias
NAO HA GARANTIAS !
5 - Risco
ALTO RISCO DE PERDA DE DADOS !
INDISPENSAVEL USO DE NO BREAK !
6 - Visão geral
Para o meu projeto utilizei a versão 7.4 do postgres
com Slackware 9.0 com kernel recompilado
O computador utilizado é um Atlon 1.8 com 1.5 GB de Ram com hd de 40G
Um no break de 1.2 KVA com sistema UPS
6.1 algoritimo básico
Ligar computador
Criar o ramdrive
Instalar o postgres no ramdrive
Restaurar o banco de dados do HD para o ramdrive
Iniciar um sistema altomatico de commit a cada x segundos + tempo da copia ( o meu sistema preve uma perda de 1 minuto de processamento em caso de falha) interceptar desligamento gravar copia no hd desligar
6.2 kernel
Pode ser necessario recompilar o kernel para habilitar o gerenciamento de grandes quantidades de memoria
6.3 Scripts
#--------------rc.M
/etc/rc.M # Arquivo executado quando slackware entra no runlevel 3
#!/bin/sh
echo "iniciando log do servidor"
syslogd
echo "configurando teclado"
loadkeys br-abnt2
echo "Definindo nome do servidor"
hostname postgres.servidor
echo "Configurando rede"
/sbin/ifconfig lo 127.0.0.1 >> /dev/null 2>&1
/sbin/ifconfig eth1 192.168.1.2 netmask 255.255.255.0 >> /dev/null 2>&1
#inicio da configuração do postmaster
echo "Ativando Postmaster"
echo "Inicializando Ram drive"
mount -t tmpfs ramdrive /mnt/ramdrive -o size=1000M # cria um ramdrive de 1GB na memoria ( o dobro do tamanho do meu banco de dados)
mkdir /mnt/ramdrive/pgdata # cria o diretorio de dados do postgres
chown -R postgres.root /mnt/ramdrive/pgdata # ajusta os direitos
chmod -R 7777 /mnt/ramdrive/pgdata
echo "inicializando Postgres"
rm -f /tmp/.*PGSQL* # não deixa o postmaster parar em caso de reinicio por falha
su postgres -c "/bin/initdb -D /mnt/ramdrive/pgdata -U root >> /var/log/postmaster.log 2>&1" # inicia o banco de dados padrao
su postgres -c "/bin/postmaster -D /mnt/ramdrive/pgdata >> /var/log/postmaster.log 2>&1 &" # ativa o postgres
sync
echo "Restaurando banco de dados" ;
sleep 10
/bin/createdb rotas
/bin/psql rotas -f /commit/copia.sql >> /var/log/postmaster.log 2>&1
echo "Ativando sistema de copia continuada"
/bin/commit >> /var/log/commit.log 2>&1 &
echo "Ativando httpd"
httpd
echo "Ativando sshd"
sshd
echo "Ativando inetd"
inetd
#/bin/rc.0 executado quando o computador é desligado ou reiniciado
#! /bin/sh
PATH=/sbin:/etc:/bin:/usr/bin
echo "desligando sistema de copia"
killall commit
echo "Copiando banco de dados"
/bin/pg_dump rotas > /commit/copia.sql
echo "Desligando postmaster"
killall postmaster
echo "Removendo ramdrive"
umount /mnt/ramdrive
echo "paralisando processos"
killall5 -15
sleep 5
killall5 -9
umount -a
if [ "$command" = "reboot" ]; then
echo "Rebooting."
reboot
else
poweroff
fi
#commit - Gravaçaõ continuada
#!/usr/bin/perl
print "Gravacao continuada\n";
while ( 1) {
sleep 60;
# espera 60 segundo para iniciar a proxima copia ( voce pode ajustar este tempo para até 6 neste caso o tempo
#total de processamento perdido em caso de falha equivale ao tempo que o computador levar para copiar o banco de dados da memoria
#para o hd + 10 segundos
#tempos menores não fazem sentido num sistema raiserfs porque o intervalo padrão do commit do raiser é de 5 segundos
# a menos que voce altere este parametro ou utilize um de um flush no disco, como nunca tive problemas com o reiser preferi não mexer nos
#valores padrão
# o sistema vai criar arquivos sequenciais num periodo de 24 horas iniciando em
# c0000.tmp.gz até c2359.tmp.gz
#dependendo de como o tempo for configurado podera haver buracos entre um e outro
#
($horario=`date +%d%m%y%H%M%S`) =~ s/\n//g;
$hora=substr($horario,6,2);
$minuto=substr($horario,8,2);
$segundo=substr($horario,10,2);
print "Hora: $hora Minuto:$minuto Segundo:$segundo\n";
$nomefile="c". substr($horario,6,4);
print "Copiando banco de dados\n";
$cmd="pg_dump rotas > /commit/$nomefile.tmp 2>&1";
$resultado = system($cmd);
if ( $resultado eq 0 ) {
print "renomeando arquivos \n";
# o arquivo copia.sql equivale a ultima copia valida por isso ele é movido de de $nomefile para
# copia.sql para evitar problemas de falhas durante a copia
#mesmo assim se houver um crash bem na hora do mov o
#copia.sql pode ficar inconsistente necessitando uma intervenção técnica
#que restaure o ultimo chhmm.tmp.gz valido para o copia.sql
#e depois
#dropdb rotas
#createdb rotas
#psql rotas -f copia.sql
`cp /commit/$nomefile.tmp /commit/copia.presql`;
`mv /commit/copia.presql /commit/copia.sql`;
print "compactando $nomefile.tmp\n";
`/usr/bin/gzip -f /commit/$nomefile.tmp`;
}
else { print "Erro $resultado no servidor PostgreSQL \n "; print `cat /commit/$nomefile.tmp`;}
print " Aguardando\n"; }
7 - Dicas e cuidados
É indispensável o uso de no-break para saber se o espaço em hd é suficiente multiplique o tamanho do seu ultimo chhmm.tmp.gz x 1440 por exemplo se o seu c1200.tmp.gz for igual a 1M voce precisara de pelo menos 1440M 1.G giga de espaco para o diretorio commit neste caso seria aconselhavel ter pelo menoz 3GB de espaço no disco eu tambem tenho no meu script original uma forma de copiar para um cdrw de hora em hora seria aconselhavel tambem instalar um no-break com ups para desligar automaticamente o servidor em caso de queda de energia eletrica
Com este sistema consegui abaixar tempos de query de mais 2 minutos para 12 segundos.
Se algum outro louco se aventurar e tiver sucesso ou alguma evolução da idéia por favor: mailto:porducel@bol.com.br
Autor: Arnaldo Luiz Estevão
Email: porducel@bol.com.br
» Postado por: Roberto em abril 22, 2004 04:06 PM, 200.96.235.:
Cara a idéia é muito boa para quem precisa de muita performase. Não sei se usaria este esquema em ambiente critico , onde a integridade dos dados podem representar prejuizos...
» Postado por: arnaldo em abril 23, 2004 12:28 AM, 200.140.26.:
Roberto, voce consideraria uma empresa de onibus intermunicipal com cerca de 15 guiches de passagens, 12 agencias de turismo e 30 pontos de despacho de cargas on-line um sistema crítico ?
Estamos trabalhando desta forma ha cerca de 5 meses e nunca tivemos problemas.
Se voce possui um sistema extremamente crítimo (dos quais vidas humanas possam depender por exemplo) poderia trabalhar possibilidade de uma gravação dupla direto do aplicativo com duas coneções abertas uma para o banco de dados no ramdrive e outra para um banco de dados no HD
uma espécie de cache ativo ou outro esquema qualquer de replicação que otimizaria apenas as leituras
Alias esta tambem seria uma solução em um banco de dados extremamente grande que levasse minutos para ser inteiramente copiado para o hd
» Postado por: Rodolfo Penha em maio 3, 2004 01:34 PM, 200.207.158:
Achei ótima a solução. O que poderia ser feito para melhorar a confiabilidade do sistema, seria criar um sistema redundante. Uma vez li um artigo sobre a criação de RAIDS de banco de dados (infelizmente não tenho o link, mas tenho certeza que uma busca no google resolve). O mais interessante é que as bases de dados não precisam necessariamente ser a mesmas. Por exemplo, vc pode ter um servidor rodando PostgreSQL e outro rodando MySQL. Neste artigo específico, era utilizado um driver em java (JDDBC se não me engano) que abstraia totalmente a camada de interface com as bases de dados, ou seja, sua aplicação funcionaria como se estivesse sendo utilizada apenas uma base de dados. Além disso, poderiam ser adicionados mais bases ai sistema que o próprio driver se encarregava de sincronizar os dados.
Muito interessante a idéia. Aconselho que quem precise de uma alta performance/redundância (em alguns casos o ganho de performance era de ~ 6x dependendo do tipo de RAID utilizado) dê uma procurada na internet.
» Postado por: Pierre em maio 23, 2004 07:43 PM, 201.2.229.2:
Em relação a velocidade de acesso, com certeza oa ganhos serão enormes. Mas sinceramente falando, do ponto de vista profissional é algo muito critico e imagino que dificilmente alguem vai implementar esta solução dentro de uma empresa. O custo de hardware para melhorar a performance de aplicações deste tipo compensam a segurança, outro detalhe que a performance dos bancos de dados, a maioria das vezes se dá devido a perfeita construção das querys no banco de dados.
Enfim, parabenizo pela pesquisa e pelo esforço, mas quanto ao uso profissional, acho muito temeroso usar esta solução.
É só uma opinião, respeito o seu estudo e a pesquisa e sobretudo a preocupação em compartilhar a pesquisa.
» Postado por: arnaldo em maio 24, 2004 04:57 PM, 200.96.213.:
Pierre
Estou trabalhando agora (e quando estiver pronto vou divulgar) num sistema de espelho entre dois servidores com gravação simultânea em ambos deste modo o sistema de gravação continuada não precisa mais ser continuo porque a possibilidade dos dois servidores cairem ao mesmo tempo e menor que a probilidade de defeito em um sistema convensional , na realidade eu estou investindo em hardware, mas no sentido de tornar a idéia tão segura quando o padrão normal como estou conseguindo obter respostas em real time não consigo mais dar marcha a ré no projeto porque os usuarios reclamaram muito quando precisei fazer uma manutenção e deixei um servidor de reserva funcioando durante algumas horas no qual não havia o mesmo esquema a idéia tomou força quando comecei a ter tempos altos de up-time (mais de 180 dias) e percebi que a queda de servidores com Linux estava começando a se tornar um problema despresível
» Postado por: PSi666 em junho 16, 2004 09:38 AM, 200.225.157:
Experimente colocar o queue do mail (no caso de servidores MX) ou o diretório temporário do sophie para ver como fica rápido... :-)
» Postado por: Alexandre Correa em junho 29, 2004 07:06 PM, 200.202.237:
Qual o tamanho maximo que o banco poderá atingir ?
tenho um banco de dados com 42Gb ..
e performance neste caso é importante...
» Postado por: arnaldo em julho 1, 2004 11:51 AM, 201.3.10.50:
Alexandre eu acredito que a limitação seja a quantidade de memoria ram necessária neste caso que teria de ser pelo menos 80GB, ai eu sou obrigado a concordar com o Pierre seria melhor investir em hds de alta capacidade de velocidade e acredito que até mais barato, mas se preço não for o seu problema sem dúvida nenhum nenhum hd por mais rapido que seja conseguira ser tão rapido quanto uma ram uma vez que ele esta limitado por fatores mecanicos, neste caso a preocupação seria o tempo necessário para copiar o banco de dados da memoria para o hd, porque este seria o tempo de processamento que voce perderia em caso de falha, o que não dispensaria um hd super rapido para diminuir este tempo, qualquer coisa pode me enviar um email para trocarmos ideias
» Postado por: Cleber Adriani em novembro 3, 2004 11:53 AM, 200.232.29.:
A idéia é realmente ótima, mas com relação a cópia de segurança a cada 1 minuto, como funciona?
O sistema copia TODO o banco da RAM para o disco? Se sim, isso não acaba deixando o sistema mais lento? Qual a porcentagem de ganho de performance que você obteve com este processo?
O Arquivo Histórico do BR-Linux.org mantém no ar (sem alteração, exceto quanto à formatação) notícias, artigos e outros textos publicados originalmente no site na segunda metade da década de 1990 e na primeira década do século XXI, que contam parte considerável a história do Linux e do Open Source no Brasil. Exceto quando indicado em contrário, a autoria dos textos é de Augusto Campos, e os termos de uso podem ser consultados na capa do BR-Linux.org. Considerando seu caráter histórico, é provável que boa parte dos links estejam quebrados, e que as informações deste texto estejam desatualizadas.