[firebase-br] Super Server e dois núcleos

[Eduardo Bahiense]

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
>