Thread: Re: BUG #13515: Much higher disk writes after postgres upgrade 9.4.3->9.4.4

Do not think so. It was a continuous disk write even when there was no
autovacuum process running. It was happening even on a database in which
there were no inserts/deletes/modify and did vacuum manually.


On Thu, Jul 23, 2015 at 9:29 PM, Kevin Grittner <kgrittn@ymail.com> wrote:

> Sushant Sinha <sushant@indiankanoon.com> wrote:
> > On Thu, Jul 23, 2015 at 10:27 AM, <pgsql-bugs-owner@postgresql.org>
> wrote:
>
> >> After upgrade from postgres 9.4.3 to 9.4.4 I am seeing constant disk
> writes
> >> of 4-8MB/s in the background in production. I verified it using iotop
> and
> >> vmstat. iotop shows "Total Disk Write" to be minuscule (like
> 10-100Kbps). It
> >> is affecting runtime performance. I never noticed this issue with
> postgres
> >> 9.4.3.
> >>
> >> I increased the shared buffers from 128MB to 1GB and still didn't see
> any
> >> benefit.
> >>
> >> The website (http://indiankanoon.org) mostly uses text search with gin
> index
> >> and some logging of click through data. The main database is replicated
> >> using "streaming asynchronous replication".
> >>
> >> I am going to downgrade it to 9.4.3 to see if the upgrade was the real
> >> problem. But just wanted to check if anyone else noticed it.
>
> > Ok. There is a problem with the patches that went in between
> > Postgres 9.4.3->9.4.4
> >
> > I downgraded to Postgres 9.4.3 and everythig is normal. "Actual
> > disk writes" in iostat is pretty much as "Total disk writes"
> > (between 50-100 Kbps and not in Mbps). "vmstat 1" also shows no
> > excessive disk writes.
>
> Did you notice whether it was an autovacuum process causing the
> additional I/O in 9.4.4?  There were some bugs in 9.4.3 that failed
> to vacuum away old multi-transaction tracking structures in a
> timely fashion, causing data loss and database corruption.  Once
> you upgraded a background task was probably trying to make up for
> the lack of timely maintenance, so that you would not experience
> those problems.  Downgrading may be a little faster for a little
> while, but you're almost certain to regret doing it very soon....
>
> --
> Kevin Grittner
> EDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
>
> --
> Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs
>