From: | Greg Smith <greg(at)2ndquadrant(dot)com> |
---|---|
To: | Andras Fabian <Fabian(at)atrada(dot)net> |
Cc: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: PG_DUMP very slow because of STDOUT ?? |
Date: | 2010-07-13 14:29:03 |
Message-ID: | 4C3C782F.4080106@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Andras Fabian wrote:
> So the kernel function it is always idling on seems to be congestion_wait ...
Ugh, not that thing again. See
http://www.westnet.com/~gsmith/content/linux-pdflush.htm ; that chunk of
code has cost me weeks worth of "why isn't the kernel writing things the
way I asked it?" trouble in the past. I know the kernel developers have
been fiddling with pdflush again recently, they might have introduced
yet another bug into how it handles heavy write volume. You can reduce
dirty_ratio and dirty_background_ratio to try and improve things, but
the congestion code will thwart any attempt to make them really low.
You might monitor what shows up as "Dirty:" in /proc/meminfo to see if
that lines up with the slow periods; example of what bad output looks
like at
http://notemagnet.blogspot.com/2008/08/linux-write-cache-mystery.html
--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com www.2ndQuadrant.us
From | Date | Subject | |
---|---|---|---|
Next Message | Andras Fabian | 2010-07-13 14:35:16 | Re: PG_DUMP very slow because of STDOUT ?? |
Previous Message | Andras Fabian | 2010-07-13 14:16:23 | Re: PG_DUMP very slow because of STDOUT ?? |