Subject | Re: [firebird-support] Re: 100% CPU Usage |
---|---|
Author | Jukka Raisio |
Post date | 2004-08-31T18:53:21Z |
This may be one faq-item but...
I just noticed surprising fact with BDE how it takes 100% CPU for many
seconds.
TDatabase connection is kind of one at the time connection. If you open
query
with large result set, it opens quicly and gives you those lines which you
fetch.
The but section is that if another query is opened for single line with same
TDATABESE connection, the first query is fetched thrue and before that the
simple
query is executed. The only thing what can be seen is that simple query
takes lots of time
if an another TDATEBASE is used for the simple/second query, the first one
does not
do anything unexpected...
I suppose that same thing can occur with other kind of environments
by the way, thanks about your book ./heLen
-jukka
I just noticed surprising fact with BDE how it takes 100% CPU for many
seconds.
TDatabase connection is kind of one at the time connection. If you open
query
with large result set, it opens quicly and gives you those lines which you
fetch.
The but section is that if another query is opened for single line with same
TDATABESE connection, the first query is fetched thrue and before that the
simple
query is executed. The only thing what can be seen is that simple query
takes lots of time
if an another TDATEBASE is used for the simple/second query, the first one
does not
do anything unexpected...
I suppose that same thing can occur with other kind of environments
by the way, thanks about your book ./heLen
-jukka
----- Original Message -----
> Dear Helen;
>
> Thank you for your "sermon", in fact, I got it in a Sunday.
>
> For your information our application is using the option "Forced
> Writes" with zero interval as per the Bolrdans's support mentioned in
> your previous message.
>
> On daily basis we are running maintennance routines using the
> commands GFIX and GBACK to refresh the data base.
>
> Initially we were using 16K as database cache, for testing purposes
> we changed it to 32K. Recently we have increased the database cache
> to 64, as a result the application required more memory and we had an
> slightly increasing in the performance.
>
> However the CPU peaks are still ocurring so often and the system in
> these circumstances is almost useless.
>
> Sorry for resume this subject but I'm completelly lost. I grabbed the
> screens of performance monitor during a peak. You can take a look on
> it by accessing