Michael Vilhelmsen schrieb am 07.06.2012 um 10:45 (-0000):

> > No - they're just using a lot of transactions. Login and logout
> > match your comparative data below. Autocommit mode would easily
> > account for the higher number of transactions.
>
> This might be true, but along this we have had some meetings where
> I had told them that I would have them to START and COMMIT every
> transaction manually.

Maybe have some more meetings :)

> Whatever kind of connection they have and whatever they use it for
> they do connect/disconnect more than 1700 times per minute.

They do COMMIT a lot, thereby exercising your triggers, but not CONNECT.
This is obvious from the data you posted.

Is there an index on the table the COMMIT TRIGGER is INSERTing data
into? If so, at 1700 INSERTs per second, that would create a pretty
nice write load. And even without an index it is not negligible.

> They have had a connection fore some month.
> The first 2½ month there where no problems. And they had a 20-80
> connect/disconnect per minute. I still find this to be a lot given
> what they do, but it worked.
>
> Then suddenly this rose to 1700+. And the server started to die.
> I contacted them, and for a week they disabled one thing, and the
> connect/disconnect went dowen to 20-80.
> And the problem disappeared.
> NOw the day before yesterday they enabled again, and I started to die
> again.
>
> My logical conclussion is that this is causing the problem.
> It runs smoothly without this. It dies with this.

Yes. Just the details of what "this" is are not clear.

> Disc is not full.
> OS in is drive C. 67Gb. Free 54 Gb
> DB is on driver D. 135 Gb. Free 80 Gb
>
> There is already nothing running on the server.

A Firebird under heavy load is running, possibly eating lots of memory
and stressing the disk.

> No errors in any logs. Except Firebird.

Not a sysadmin, but I don't find that surprising if it is a dedicated
Firebird server where Firebird is the only program causing load on the
server …

Michael