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

[Carlos H. Cantu]

"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