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

[Eduardo Bahiense]

Valeu Cantu

Vou conversar com a minha equipe e ver o que decidimos. Posto aqui 
qualquer coisa que ache relevante compartilhar.

Abraço


Eduardo

Carlos H. Cantu escreveu:
> "Nativamente" não tem como vc atrelar o processo do FB à uma CPU no Linux.
> 
> Me parece que existem alguns utilitários para linux que podem fazer
> isso pra vc, mas nunca usei nessa situação, portanto não sei se
> teria "efeitos colaterais" ou mesmo se poderia comprometer a
> estabilidade. De qq forma, dê uma olhada:
> 
> http://www.cyberciti.biz/tips/setting-processor-affinity-certain-task-or-process.html
> http://aplawrence.com/Basics/taskset.html
> 
> Pelos dados que vc passou, realmente o problema parece não o sweep. No
> entanto, o ideal seria vc tirar uma estatística no momento em que o
> sistema estiver apresentando lentidão.
> 
> []s
> Carlos H. Cantu
> www.warmboot.com.br - www.firebirdnews.org
> www.FireBase.com.br - blog.firebase.com.br
> 
> EB> Olá Douglas e Cantu
> 
> EB> Obrigado pelas respostas.
> 
> EB> Quanto ao Garbage Collection, não acho que esteja interferindo, mas 
> EB> confesso que não sou de todo à vontade com a análise do gstat, por 
> EB> exemplo, o banco de 3GB, neste momento, está assim:
> 
> EB>          Flags                   0
> EB>          Checksum                12345
> EB>          Generation              1242655
> EB>          Page size               4096
> EB>          ODS version             11.1
> EB>          Oldest transaction      1239737
> EB>          Oldest active           1239738
> EB>          Oldest snapshot         1239673
> EB>          Next transaction        1239869
> EB>          Bumped transaction      1
> EB>          Sequence number         0
> EB>          Next attachment ID      2778
> EB>          Implementation ID       19
> EB>          Shadow count            0
> EB>          Page buffers            0
> EB>          Next header page        0
> EB>          Database dialect        3
> EB>          Creation date           Oct 1, 2008 1:39:33
> EB>          Attributes              force write
> 
> EB> Tenho analisado no final da tarde e as diferenças sem mantêm mais ou 
> EB> menos as mesmas. Como fazemos backup às 05:00 e 18:15, tenho concluído
> EB> que o ciclo de backups é suficiente para não deixar o sweep interval 
> EB> chegar a 20000, mesmo porque é um banco usado, normalmente, 85% para 
> EB> consultas e comitamos tudo que gravamos, sempre. Assim, tenho atribuído
> EB> a lentidão ao nível de concorrência por recursos do hard (memória, 
> EB> processador e acesso a disco).
> 
> EB> Infelizmente, não tenho como reproduzir a carga em um ambiente de testes.
> 
> EB> A carga entre os bancos é semelhante, minha idéia era alocar os dois 
> EB> bancos de 1GB em um núcleo e o de 3GB em outro, mas observei agora que o
> EB> flag "cpuafinity" no fb.conf é "windows only" e nosso server é DEBIAN.
> 
> EB> Desta forma, pergunto: Haveria no linux alguma maneira de garantir que
> EB> uma instância do Super Server usaria um núcleo e a outra o segundo?
> 
> 
> EB> Abraço
> 
> 
> EB> 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
>