[Glass] Transaction Logs so large ....

[Otto Behrens via Glass]

> If you already know this stuff then your question would be related to
> checkpoint commits not happening in a timely manner. How that can happen and
> how to improve that is a much deeper discussion, but is usually remedied by
> changing gems to not stay with old views of the database. That can mean more
> frequent aborts for example, and starting a transaction a short time before
> making changes to commit. Just one gem staying in-transaction for a long
> time can hold up checkpoint commits. A developer logged into (and
> in-transaction) a very active database can hold up checkpoints causing a
> backlog of transactions not yet applied to extent files.

I understand that if there are gems holding onto old views with other
gems committing a lot, it may happen that more garbage than usual will
end up in the extent and the gems will take longer to commit because
they have more work to determine the write set union etc. I suppose if
things start to overflow one could create bigger and bigger
transaction logs because a gem would be committing temporary objects
to the repository.

If one install proper SigAbort handlers for gems then the gems should
be catching them and aborting, unless there are way more commits than
what the gems can react to via sig aborts? Is it in this case that the
condition may occur?

In our application, we start a number of gems that service seaside
requests. These gems (as well as the other gems we run in the
background), all have sig abort handlers. The load balancing also
helps to ensure that the seaside based application distributes work to
idle gems. So in my view, gems should be cooperating well.

In spite of this, we still see 10GB of tranlogs created in a few hours
under low load. (The db is around 23GB).

I suppose the only way to really analyse what's going on is to run
statmonitor and understand the output. From my previous attempts
though, it appears as if the Seaside infrastructure is really heavy on
transaction logs.