ibserver stops to respond on parallel selects

Hello.

I've written a script that executes 8 times the following line:

/opt/interbase/bin/isql localhost:/data/mydb.gdb -i test.sql -u SYSDBA 
-p masterkey >& test1.log &

The file test.sql just contains one line:

select count(*) from my_big_table

After executing this script ibserver stops to respond to
connection attempts and even already connected clients don't
respond any more.

IB is installed on a Linux-Server (Suse 10.1 / POSIX-threads)
with 4 Xeon processors.

With a performance monitor I can see that all processors
start to work when I start my script but after a short while
all return at the same moment to nearly 0% activity.
Sometimes one of the eight isql-processes finishes normally,
but in most cases they all hang.

The connections are still established (lsof -i) but as
mentioned before the ibserver stops to respond.

The only possibility to get out of this situation is to
kill the ibserver process.

The really strange thing is that when starting 30 times
the isql process I don't get any problems. All finish
as they should.

I already made a backup and restore without any change.

I also made the same test on another server with 2 processors
without running into any problems. The difference though
is that this smaller server uses Linux-threads.

The table that I use for the select has about 2.4 Mio. records,
60 columns and 30 indices. Again no problems with smaller tables.

At the moment I try to reproduce the error with a database
that just holds the one big table and with all data made anonymous.
If I'm able to do so I can put this DB on our server for
download.

Any idea what could be the problem?

Thanks,

Stefan

-- 
Stefan Sinne

Email: _DT_ = .

> Stefan

Unless I missed it, you don't say which version of IB you are using.




-- 
Jason Chapman
JAC2 Consultancy
Development - Consultancy - Training 
Delphi, InterBase, Firebird, OOAD, Development lifecycle assistance,
Troubleshooting projects, QA.....

Jason Chapman wrote:
>> Stefan
> 
> Unless I missed it, you don't say which version of IB you are using.
> 
> 
> 
> 
I'm using 7.5.1.

The server runs Suse Linux 10.1 for 64-bits.

I am nearly finished with creating a test-db. It took a while because
of the size of that table.

When finished I put it on our server for download together with the
script I used.

Next I will install Suse Linux 9.2 for 32-bits (what we used so far for
our customers) and try to reproduce the error with that environment.

Stefan

-- 
Stefan Sinne

Email: _DT_ = .

I finally created a test-database that you can download at

ftp://www.sss-smart.com/interbase/ibtestgbk.tgz
(ca. 20MB - backup-file that you have to restore)

and

ftp://www.sss-smart.com/interbase/ibtestgdb.tgz
(ca. 280 MB - original gdb-file / no need to restore)

(unpack with 'tar -xzf')

The test is run like

sh start.sh

Hopefully anyone with a similar environment (Suse-Linux 10.1,
64-bit, IB 7.5.1, 4 Xeon procs) will try to reproduce the
error.

Thanks in advance,

Stefan

-- 
Stefan Sinne

Email: _DT_ = .

I have installed Suse 9.2 and ran into the same problem:
with four or eight parallel selects the ibserver-process
stops to respond.

Then I inserted into the startup script the following lines:

LD_ASSUME_KERNEL=2.4.1
EXPORT LD_ASSUME_KERNEL

Now the ibserver runs with the old Linux-threads and the
problems disappeared.

The disadvantage now is the duration of the parallel selects.
I have done some comparison:

                     POSIX-threads   Linux-threads
  1 select           10 secs         10 secs
  4 parallel selects ERROR           33 secs
  6 parallel selects 18 secs         140 secs
  8 parallel selects ERROR           145 secs
10 parallel selects 44 secs         223 secs
15 parallel selects 51 secs         700 secs

Also there is a significant difference when looking at the
processor usage (with KSysguard): With POSIX-threads all
processors are running at around 90% whereas with Linux-threads
they are running around 20-25%.

Anyone can exlain this great difference in performance?

I really would prefer to run IB with POSIX-threads but
until I don't get any response/solution/idea regarding
the bug I will have to stay with the old threading model.

Is there anyone who can help me?

Thanks,

Stefan

-- 
Stefan Sinne

Email: _DT_ = .