Hello,

Recently I'm working on a significantly bigger db compared to those I used
to work on so far. Since then, I'm starting to face all sorts of slowdowns
that I cannot seem to understand/anticipate.

I thought I understood the main traps with IB/FB, but apparently, this is
not true ;-)
My db is about 10 Gb big and its biggest table, the one that is causing me
the most troubles, is about 55 million rows.

Here is a situation I faced twice and that I cannot explain myself.

- DB is Swept, OIT/OAT are in line.
- During the following ops, only one connection/transaction accesses the DB
and the FB server has the whole machine for itself.

- I import (Insert) a fair amount (e.g. 800000) of records in the said "big"
table.
- During the import, I commit every 50000 inserts.
- After the import, OIT/OAT still look nicely in line.

- I run an selectable SP that computes some stats and always return the same
resultset.
- The SP should take about 20s to return.
- First execution of that SP returns in 28s. That's ok.
- Commit.
- Second one returns in 1m28s. That's a not so OK.
- Commit.
- Third one returns in 1m50s. It's getting worse.
- Commit.
- I run a Select count(*) on the given DB just in case it requires GC (but I
guess it's useless since only inserts where done)
- Commit.
- Recompute all indices on the given table.
- Close/reopen connection
- Check Fbserver CPU usage => 0 %
- Check Server CPU usage => 0%
- Running the SP again, it now takes 2m32s !!!
- Commit.
- Guessing a few minutes.... at lost.
- Start SP again "just in case". Surprise ! it now returns in 20s as it
should.
- Each subsequent call also returns in 20s.
- Is this because it is cached ? I shutdown/restart fbserver.
- Rerun the SP. 20s again. Each time.

Does anyone have a clue of what could cause this slowdown_and_back_to_normal
thing ?

Thanks a lot.

--
Jerome