[firebase-br] Super Server e dois núcleos
Eduardo Bahiense
eduardo em icontroller.com.br
Seg Out 27 10:59:37 -03 2008
Olá Douglas e Cantu
Obrigado pelas respostas.
Quanto ao Garbage Collection, não acho que esteja interferindo, mas
confesso que não sou de todo à vontade com a análise do gstat, por
exemplo, o banco de 3GB, neste momento, está assim:
Flags 0
Checksum 12345
Generation 1242655
Page size 4096
ODS version 11.1
Oldest transaction 1239737
Oldest active 1239738
Oldest snapshot 1239673
Next transaction 1239869
Bumped transaction 1
Sequence number 0
Next attachment ID 2778
Implementation ID 19
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 3
Creation date Oct 1, 2008 1:39:33
Attributes force write
Tenho analisado no final da tarde e as diferenças sem mantêm mais ou
menos as mesmas. Como fazemos backup às 05:00 e 18:15, tenho concluído
que o ciclo de backups é suficiente para não deixar o sweep interval
chegar a 20000, mesmo porque é um banco usado, normalmente, 85% para
consultas e comitamos tudo que gravamos, sempre. Assim, tenho atribuído
a lentidão ao nível de concorrência por recursos do hard (memória,
processador e acesso a disco).
Infelizmente, não tenho como reproduzir a carga em um ambiente de testes.
A carga entre os bancos é semelhante, minha idéia era alocar os dois
bancos de 1GB em um núcleo e o de 3GB em outro, mas observei agora que o
flag "cpuafinity" no fb.conf é "windows only" e nosso server é DEBIAN.
Desta forma, pergunto: Haveria no linux alguma maneira de garantir que
uma instância do Super Server usaria um núcleo e a outra o segundo?
Abraço
Eduardo
Eduardo Bahiense escreveu:
> Boa noite senhores
>
>
> Temos hoje nosso servidor de aplicação no mesmo computador do servidor
> de dados. Por questão de escalonamento, estamos abrindo um servidor só
> pro FB, ou seja um servidor exclusivo de dados, que só terá o FB
> gerenciando 3 bancos de dados, 1 de 3GB em um HD e outros dois de +- 1GB
> cada, em outro HD. Esperamos com isso ter uma folga de hard por um bom
> tempo.
>
> Neste cenário, temos 5 processos fastcgi acessando esses 3 bancos, a
> partir de um servidor de login que diz em que base estão os dados do
> cliente logado. Assim, durante a operação normal, levantam-se até 15
> instâncias do Classic, com uma média de 350 - 500 terminais logados
> simultaneamente, servidos por esses 5 fastcgi's.
>
> Até agora, um único server deu conta, mas já começamos a experimentar
> lentidão em alguns horários de pico. O controle transacional, ao que
> parece, pela análise do gstat, está perfeita.
>
> Com esse movimento, esperamos escalonar distribuindo processamento, uso
> de memória e acesso a disco.
>
> A dúvida que nos surgiu foi a seguinte:
>
> Até agora, usamos o Classic por duas razões:
>
> 1. Se tivéssemos problema em uma conexão, seria fácil matar um processo
> e não afetar os demais.
> 2. O Classic usa os dois núcleos do procesador.
>
> Quanto à primeira, em 3 anos de operação, já temos confiança suficiente,
> o cara é "bão mesmo", não trava (claro que ficamos "mais bãos" também
> durante o tempo, corrigindo um monte de queries mau construídas).
>
> Quanto à segunda, um membro de nossa equipe fez a seguinte pergunta:
> *E se colocássemos duas instâncias do SuperServer, uma em cada porta,
> poderíamos usar o cpu afinity para que cada um usasse um núcleo?*
>
> Bem, isso porque, com 15 instâncias gerenciando 3 bases que guardam
> dados de +-300 clientes, o overhead de memória ao longo do dia é grande
> com o cache do classic, mas como fazemos backup duas vezes por dia, esse
> cache é zerado no início da manhã e final da tarde.
>
> Assim, resolvi submeter isso aos ilustres gurus e ver se alguém me ajuda
> a decidir isso antes de instalar o novo servidor.
>
>
> Abraço a todos
>
>
> Eduardo
>
>
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> Para saber como gerenciar/excluir seu cadastro na lista, use:
> http://www.firebase.com.br/fb/artigo.php?id=1107
> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
>
Mais detalhes sobre a lista de discussão lista