Re: [Slony1-general] WAL partition overloaded--by autovacuum?
От | Robert Haas |
---|---|
Тема | Re: [Slony1-general] WAL partition overloaded--by autovacuum? |
Дата | |
Msg-id | AANLkTim9s_S0LS3VtjxUVGuGOHkl_2n7YfpB3KWwdlm-@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [Slony1-general] WAL partition overloaded--by autovacuum? (Richard Yen <richyen@iparadigms.com>) |
Ответы |
Re: [Slony1-general] WAL partition overloaded--by
autovacuum?
|
Список | pgsql-performance |
On Wed, Jul 7, 2010 at 3:32 PM, Richard Yen <richyen@iparadigms.com> wrote: > On Jul 6, 2010, at 8:25 PM, Scott Marlowe wrote: > >> Tell us what you can about your hardware setup. > > Sorry, I made the bad assumption that the hardware setup would be irrelevant--dunno why I thought that. > > My hardware setup is 2 FusionIO 160GB drives in a RAID-1 configuration, running on an HP DL360 G5 > > I think I figured out the problem: > > -- I figured that pg_xlog and data/base could both be on the FusionIO drive, since there would be no latency when thereare no spindles. > -- However, I didn't take into account the fact that pg_xlog might grow in size when autovacuum does its work when vacuumingto prevent XID wraparound. I *just* discovered this when one of my other replication nodes decided to die on meand fill up its disk. > -- Unfortunately, my db is 114GB (including indexes) or 60GB (without indexes), leaving ~37GB for pg_xlog (since they aresharing a partition). So I'm guessing what happened was that when autovacuum ran to prevent XID wraparound, it takeseach table and changes the XID, and it gets recorded in WAL, causing WAL to bloat. This this the correct understanding? That seems logical (and un-fun), but I don't understand how you managed to fill up 37GB of disk with WAL files. Every time you fill up checkpoint_segments * 16MB of WAL files, you ought to get a checkpoint. When it's complete, WAL segments completely written before the start of the checkpoint should be recyclable. Unless I'm confused, which apparently I am. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
В списке pgsql-performance по дате отправления: