Problemas com driver nativo para Firebird com Delphi 2010
Boa tarde!
Gostaria de comentar com vocês um problema que tive e que se alguém também passou ou passa pudesse me ajudar.
Trabalhava com Delphi 7, DBExpress driver UIB 2 e Firebird 2.1, até ai tudo bem, migrei para Delphi 2010, usando o driver nativo, porém comecei a ter problemas com muitas transações em aberto, usei o SINÁTICA Monitor para ver o que poderia estar causando lentidão no sistema e chegou um ponto que nem abria mais o sistema.
Ambiente que o sistema trabalha:
Servidor Linux - Slackware, Quad-Core, 4gb de ram, etc etc.
Estações: Todas basicamente processadores AMD, 2GB RAM, HD 500GB e Windows 7 ultimate.
Bom mais ou menos isto ok, alguém teve problemas com este novo driver? seria a forma de programar?
Não tenho controle de transação via código, uso componentes DBWare, Uso TSqlQuery, TDataSetProvider, TClientDataset e TDatasource, uso ApplyUpdates(0), fiz uma rotina no onreconcilierror, caso ocorra algum e nada!
Apenas a lentidão, ai fiz um teste local, usando o exe antigo do Delphi 7 com UIB e o novo do Delphi 2010, nossa que diferença em performance e fechamento das transações, um select simples que fazia na base o 2010 consome muito!
Bom é mais ou menos isto, não sei se pode e se é viável mas achei este link onde vi que tiveram o mesmo problema, caso interessem:
http://comments.gmane.org/gmane.comp.db.firebase.portuguese/90741
Gostaria de trocar informações!
Obrigado
Abraços
Gostaria de comentar com vocês um problema que tive e que se alguém também passou ou passa pudesse me ajudar.
Trabalhava com Delphi 7, DBExpress driver UIB 2 e Firebird 2.1, até ai tudo bem, migrei para Delphi 2010, usando o driver nativo, porém comecei a ter problemas com muitas transações em aberto, usei o SINÁTICA Monitor para ver o que poderia estar causando lentidão no sistema e chegou um ponto que nem abria mais o sistema.
Ambiente que o sistema trabalha:
Servidor Linux - Slackware, Quad-Core, 4gb de ram, etc etc.
Estações: Todas basicamente processadores AMD, 2GB RAM, HD 500GB e Windows 7 ultimate.
Bom mais ou menos isto ok, alguém teve problemas com este novo driver? seria a forma de programar?
Não tenho controle de transação via código, uso componentes DBWare, Uso TSqlQuery, TDataSetProvider, TClientDataset e TDatasource, uso ApplyUpdates(0), fiz uma rotina no onreconcilierror, caso ocorra algum e nada!
Apenas a lentidão, ai fiz um teste local, usando o exe antigo do Delphi 7 com UIB e o novo do Delphi 2010, nossa que diferença em performance e fechamento das transações, um select simples que fazia na base o 2010 consome muito!
Bom é mais ou menos isto, não sei se pode e se é viável mas achei este link onde vi que tiveram o mesmo problema, caso interessem:
http://comments.gmane.org/gmane.comp.db.firebase.portuguese/90741
Gostaria de trocar informações!
Obrigado
Abraços
César
Curtidas 0
Respostas
Anderson
24/09/2010
Boa tarde, já tive problemas similares, então, segue algumas dicas:
O número de conexões pode estar com limites no serviço xinetd / inetd. Verifique os parâmetros de configuração em /etc/xinetd.conf ou /etc/inetd.conf (instances e per_source). Caso tenha certeza de que o servidor dará conta do recado das máquinas que vão se conectar, pode colocar:
instances = UNLIMITED
per_source = UNLIMITED
Se tiver dúvidas, vá incrementando os números, baseando-se no número máximo de conexões simultâneas por estação + outros tipos de conexões que usem o xinetd / inetd + alguma margem de segurança.
* Lembre-se de reiniciar os serviços de rede (ou o servidor) para que as alterações tenham efeito.
Para ver o número total de conexões do Firebird no linux, use:
netstat -n | grep -v 139 | grep 3050 | wc -l
Esta rodando a versão Classic ou SuperServer ?
Classic não compartilha cache com outras conexões, é mais lenta, mas muito mais segura, pois utiliza a concepção atual da maioria dos SGBD's de marcado, tal como Oracle, Sybase ou MSSQL.
SuperServer compartilha cache com outras conexões, é mais rápida, mas tem problemas com muitas conexões simultâneas e um erro de uma conexão pode detonar com as demais conexões (principalmente transações não fechadas). Na arquitetura "SuperServer" quando uma conexão é terminada, na realidade é terminada uma thread, então a memória alocada pode ficar mais tempo no servidor do que você gostaria e ainda trazer problemas fantasmas (vem e vão do nada).
Qual versão (Classic ou Server) esta instalada no Linux:
a) O script changeGdsLibraryCompatibleLink.sh no diretório bin do Firebird
somente é disponibilizado com instalações Classic Server.
ou
b) rpm -qa | grep -i firebird retorna o pacote que terá em parte do nome o CS para Classic Server ou SS para SuperServer (comando para distros que utilizem o RedHat Package Manager)
Exemplo:
FirebirdSS-2.x...
FirebirdCS-2.x...
Sugestões (o DBExpress tem suas vantagens, mas cobra seu preço por trabalhar com vários SGDB's):
a) Use a versão Classic Server (segura e estável, sem dores de cabeça, assim como o Linux)
b) Configure o xinetd.conf ou inetd.conf (instances = UNLIMITED e per_source = UNLIMITED)
c) Revise o código da sua aplicação. Se houver possibilidades, quando o usuário sair de uma opção, feche
a conexão (se ficou algo "pendurado", vai liberar - e manter o sistema sempre leve).
d) Retorne sempre o menor número de registros possíveis em suas consultas SQL, para otimizar a performance de sua aplicação, diminuir o tráfego de rede e poupar recursos do servidor.
Abraços,
Anderson:.
O número de conexões pode estar com limites no serviço xinetd / inetd. Verifique os parâmetros de configuração em /etc/xinetd.conf ou /etc/inetd.conf (instances e per_source). Caso tenha certeza de que o servidor dará conta do recado das máquinas que vão se conectar, pode colocar:
instances = UNLIMITED
per_source = UNLIMITED
Se tiver dúvidas, vá incrementando os números, baseando-se no número máximo de conexões simultâneas por estação + outros tipos de conexões que usem o xinetd / inetd + alguma margem de segurança.
* Lembre-se de reiniciar os serviços de rede (ou o servidor) para que as alterações tenham efeito.
Para ver o número total de conexões do Firebird no linux, use:
netstat -n | grep -v 139 | grep 3050 | wc -l
Esta rodando a versão Classic ou SuperServer ?
Classic não compartilha cache com outras conexões, é mais lenta, mas muito mais segura, pois utiliza a concepção atual da maioria dos SGBD's de marcado, tal como Oracle, Sybase ou MSSQL.
SuperServer compartilha cache com outras conexões, é mais rápida, mas tem problemas com muitas conexões simultâneas e um erro de uma conexão pode detonar com as demais conexões (principalmente transações não fechadas). Na arquitetura "SuperServer" quando uma conexão é terminada, na realidade é terminada uma thread, então a memória alocada pode ficar mais tempo no servidor do que você gostaria e ainda trazer problemas fantasmas (vem e vão do nada).
Qual versão (Classic ou Server) esta instalada no Linux:
a) O script changeGdsLibraryCompatibleLink.sh no diretório bin do Firebird
somente é disponibilizado com instalações Classic Server.
ou
b) rpm -qa | grep -i firebird retorna o pacote que terá em parte do nome o CS para Classic Server ou SS para SuperServer (comando para distros que utilizem o RedHat Package Manager)
Exemplo:
FirebirdSS-2.x...
FirebirdCS-2.x...
Sugestões (o DBExpress tem suas vantagens, mas cobra seu preço por trabalhar com vários SGDB's):
a) Use a versão Classic Server (segura e estável, sem dores de cabeça, assim como o Linux)
b) Configure o xinetd.conf ou inetd.conf (instances = UNLIMITED e per_source = UNLIMITED)
c) Revise o código da sua aplicação. Se houver possibilidades, quando o usuário sair de uma opção, feche
a conexão (se ficou algo "pendurado", vai liberar - e manter o sistema sempre leve).
d) Retorne sempre o menor número de registros possíveis em suas consultas SQL, para otimizar a performance de sua aplicação, diminuir o tráfego de rede e poupar recursos do servidor.
Abraços,
Anderson:.
GOSTEI 0
César
24/09/2010
Boa tarde Anderson!
Obrigado pelas dicas estarei verificando pois estou hoje no cliente, rsrsrs, a versão do Firebird que instalamos foi FirebirdCS-2.1.3.18185-0.i686, mas o que impressionou mesmo foi as diferenças de performance comparando os executáveis do Delphi 7 (UIB 2) x Delphi 2010 (Driver Nativo).
Voltei para o Delphi 7 até ter certeza e entender então o ambiente, a principio achei/o que seja algum problema com o Driver nativo, mas pode ser que a forma de programar, configuração de ambiente, enfim seja diferente para ele, estou em busca de informações.
Como disse com o Delphi 7 está tudo ok, sem problemas!
Obrigado
Abraços
César
Obrigado pelas dicas estarei verificando pois estou hoje no cliente, rsrsrs, a versão do Firebird que instalamos foi FirebirdCS-2.1.3.18185-0.i686, mas o que impressionou mesmo foi as diferenças de performance comparando os executáveis do Delphi 7 (UIB 2) x Delphi 2010 (Driver Nativo).
Voltei para o Delphi 7 até ter certeza e entender então o ambiente, a principio achei/o que seja algum problema com o Driver nativo, mas pode ser que a forma de programar, configuração de ambiente, enfim seja diferente para ele, estou em busca de informações.
Como disse com o Delphi 7 está tudo ok, sem problemas!
Obrigado
Abraços
César
GOSTEI 0
Iran Silva
24/09/2010
Até hoje tenho este problema com o Delphi 2010. Com o drive nativo firebird + delphi 2010. Piorou muito desde que mudei do delphi 2006 com drive Interbase.
GOSTEI 0