Subject | random slowdowns |
---|---|
Author | Ferda Brabenec |
Post date | 2005-06-12T13:34:45Z |
Hi,
we are running Firebird Superserver 1.5[1-2] on a Linux server. It serves data
to a web application. We are accessing FB from a multithreaded CORBA backend
server through ODBC (UnixODBC driver manager + Easysoft ODBC FB/IB driver).
Everything works fine until moderate load appears. Then randomly some
of SQL* calls are processed 100-1000x slower then usually. We started to
log timestamps of some execution points when the processing gets too slow.
It seems that the slowdown may happen with any arbitrary ODBC call such as
SQLNumResulCols, SQLDescribeCol, SQLBindCol, SQLExecute. Sorrounding
ODBC calls from a given thread are regularly fast.
This slowdown appears even if a low number of db connections (such as 5) is
being used. Our proprietary connection pool allocates additional connections
when needed but this is not the case.
We have tried 2 Xeon-based servers with various setup combinations of
HW : single/double cpu, , HT on/off
kernels : 2.4/2.6, smp/non-smp, pthread/nptl
and also we tried to collocate/dislocate application modules on 1-3 hosts
and nothing seems to affect these slowdowns.
Classic server perfomance was noticably weaker so we did not experiment
with that build at all.
So I want to ask if anybody has/had similar problem or if anybody has
a clue how to cope with this.
TIA, Ferda
we are running Firebird Superserver 1.5[1-2] on a Linux server. It serves data
to a web application. We are accessing FB from a multithreaded CORBA backend
server through ODBC (UnixODBC driver manager + Easysoft ODBC FB/IB driver).
Everything works fine until moderate load appears. Then randomly some
of SQL* calls are processed 100-1000x slower then usually. We started to
log timestamps of some execution points when the processing gets too slow.
It seems that the slowdown may happen with any arbitrary ODBC call such as
SQLNumResulCols, SQLDescribeCol, SQLBindCol, SQLExecute. Sorrounding
ODBC calls from a given thread are regularly fast.
This slowdown appears even if a low number of db connections (such as 5) is
being used. Our proprietary connection pool allocates additional connections
when needed but this is not the case.
We have tried 2 Xeon-based servers with various setup combinations of
HW : single/double cpu, , HT on/off
kernels : 2.4/2.6, smp/non-smp, pthread/nptl
and also we tried to collocate/dislocate application modules on 1-3 hosts
and nothing seems to affect these slowdowns.
Classic server perfomance was noticably weaker so we did not experiment
with that build at all.
So I want to ask if anybody has/had similar problem or if anybody has
a clue how to cope with this.
TIA, Ferda