Re: db size growing out of control when using clustered Jackrabbit
| От | Gary Webster |
|---|---|
| Тема | Re: db size growing out of control when using clustered Jackrabbit |
| Дата | |
| Msg-id | CAEHjwJ4qf2emMPKadyEkXyFVBbeMBNKjNo0ssTPfVGbxXfRazw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: db size growing out of control when using clustered Jackrabbit ("Joshua D. Drake" <jd@commandprompt.com>) |
| Ответы |
Re: db size growing out of control when using clustered Jackrabbit
|
| Список | pgsql-admin |
On Tue, Jul 24, 2012 at 1:41 PM, Joshua D. Drake <jd@commandprompt.com> wrote:
On 07/24/2012 08:58 AM, Gary Webster wrote:Hello.
Thanks for the response.
There are several 'idle in transaction' on this server/app, but to a
different db/schema.
This is a cluster issue, not a database issue. So if you have an idnle in transaction, then it is affecting your JCR schema as well.
OK, how do I track/debug/stop the "idle in transaction"s ?
The "repository" (JCR) schema has only a few 'idle', none 'in transaction' .I mean autovacuum.
By "routine maintenance", do you mean autovacuum, or something else?
I was hoping to find more of a 'root cause' (eg. jackrabbit config) for this issue.
I can't believe that this table is supposed to be getting so big, to even require much vacuuming.
I can't believe that this table is supposed to be getting so big, to even require much vacuuming.
That is a problem too.Autovacuum does appear to usually get 'auto-canceled' by a lock.
OK, I am trying to find out why this is happening.
However, even when it runs successfully, it doesn't seem to help with
this ws_bundle Toast table size.
It won't if you have the above idle in transactions, regardless of database.
Sincerely,
jD
--
Command Prompt, Inc. - http://www.commandprompt.com/
PostgreSQL Support, Training, Professional Services and Development
High Availability, Oracle Conversion, Postgres-XC
@cmdpromptinc - 509-416-6579
В списке pgsql-admin по дате отправления: