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

ftp://ftp.datacontrol-es.com.br
Login: firebird
Password: helen

Thanks for your cooperation.

Best regards
Carlos Eduardo






--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@t...>
wrote:

> Carlos,
>
> At 11:05 PM 28/08/2004 +0000, you wrote:
> >Hi All;
> >
> >So far I had no answer for the msg below. Could you please help me?
> >
> >Regards
> >Carlos Eduardo
>
> If you are sure you properly eliminated the client library problem -

that

> you did not try to solve the problem by simply copying a renamed
> fbclient.dll - then the next thing to comment about is this:
>
> >However I'm having, too frequently, CPU usage reports with peaks of
> >100% CPU usage for a period of 10-20 seconds, in simple queries,
> >which is affecting the system performance in the client machines.

For

> >your information I don't have other relevant services running in

the

> >same server.
>
> These 10-20 second burst of CPU usage might be nothing more than

automatic

> sweeping. Though undesirable, it's not unusual with IBX

applications to

> have a lot of uncollected garbage hanging around for long periods,

that the

> background garbage collector can't touch. It remains until the

threshold

> set by the sweep interval is reached, prompting an automatic sweep.

Your

> bursts of heavy CPU activity are quite likely to be a sign that a

sweep is

> happening.
>
> The usual cause for this condition with IBX applications is the

default

> behaviour of IBX with regard to committing transactions. It uses
> CommitRetaining, or "soft commit". It is like commit in that it

commits

> pending changes; but, unlike commit, it does not release the

garbage (old

> record versions) for cleanup by the GC thread. So, if you write
> applications that never call Commit explicitly, or do not do so

often

> enough, you will get auto sweeps occurring.
>
> The standard Borland support response to this problem is to

say "Set the

> sweep interval to zero and stop the auto sweeps." This "solution"

then

> gives rise to another (worse) problem. The IBX application

continues to

> stack up garbage, and to increase the size of the memory structure

that

> holds information about "interesting" transactions. Performance

gets

> slower and slower and, eventually, the server freezes or crashes

when it

> runs out of memory.
>
> If you disable auto sweeping, you *must* do manual sweeps - and do

them

> often enough to keep ahead of the buildup rate that is set by your
> application's (mis)behaviour. It's a total myth that sweeping can

be

> ignored. It's also a fact that applications written to take care

that

> transactions become "uninteresting" as soon as possible do not

exhibit

> garbage buildup, memory-hogging or CPU-hogging.
>
> Oh dear, a sermon. It must be Sunday.
>
> ./heLen