Performance issue.
I changed my code from using stored procedures to a simple SQL insert
and now the performance is living up to my expectations. Inserting the
16.000+ rows now takes a mere 22 seconds. Still a tad slow, but it is a
start ;-)
André Jager wrote:
The "work around" using a parameterized query seems to work. I changed
it and now it is happily running without the extraordinary memory
consumption. However firebird.exe CPU is at 100% and inserting the data
is dead slow. I will run some additional tests to see if I can identify
the source of the performance problems. I already disabled all indexes
on the table I am inserting on but doesn't seem to fix the problem.
If I can help to identify if there is bug, I am more than happy to do
so. However, I looked on the internet and all documentation found on
the Firebird server did not help me to see what is going on in the
firebird server. I used the fb_lock _print utility but interpreting the
outcome of this program is rather a challenge. <!-- @page { margin:
2cm } P { margin-bottom: 0.21cm } -->
Mike Scott wrote:
Hi
I think we've got two conflicting issues here and both need to be
addressed.
1. Andre needs to find a fix or workaround to this specific problem.
2. We need to identify if there is indeed a bug in the provider and/or
Firebird.
At the moment, the responses seem to be mainly aimed at point 1. But if
we find a workaround by using parameterized queries or whatever, it
still doesn't explain why *not* doing that causes errors in the
Firebird server. That shouldn't happen. We also need to look at point 2.
Cheers,
Mike.
Oleg V. Paschenko wrote:
Hi,
Try to use parametrized
command instead of generating new sql statement in loop.
I have met this before when
I have assigned in loop new CommandText. It seems that the previous
statements are left unprepared by Firebird. I don't know whether it
is feature of Firebird or the provider. Carlos?
Regards, Oleg
I used "multiple commands". My first thought was to call the dispose as
well. So I did, but it did not change the behaviour on the server side.
I will try the prepare and see if anything changes. Maybe I did not
understand the on-line help and I am doing something wrong.
Another side effect is not only the rapidly increasing memory
requirement of the Firebird server but as well as the 100% CPU time
fbserver.exe consumes.
.
.
.
if (Counter > 1)
{
Command =
"execute procedure
ADD_FIELD_SET_DATA('"+SessionId+"', '"+FieldSetName+"',
'"+Header[j]+"', '" + Data + "', '"+ObjectId+"')";
}
FirebirdSql.Data.Firebird.FbCommand cm =
new FirebirdSql.Data.Firebird.FbCommand(
Command, c.Connection, t
);
cm.ExecuteNonQuery();
.
.
.
André Jager
|
- Re: [Firebird-net-provider] Firebird crash due to ... André Jager
-
