Hi Greg,

hmmm, thats true. Thos settings for example were much higher too (on the Ubuntu 
server), than on our old machine. 
New machine has:
- dirty_ratio = 20 (old has 10)
- dirty_background_ratio = 10 (old has 5)

But obviously setting vm.zone_reclaim_mode=0 "fixes" the problem to (which was 
"1" on new machine and "0" on old). See my latest post to Craig.

I hope using vm.zone_reclaim_mode=0 doesn't have other dire consequences :-)

Andras Fabian

-----Ursprüngliche Nachricht-----
Von: Greg Smith [mailto:g...@2ndquadrant.com] 
Gesendet: Dienstag, 13. Juli 2010 16:29
An: Andras Fabian
Cc: Craig Ringer; Tom Lane; pgsql-general@postgresql.org
Betreff: Re: [GENERAL] PG_DUMP very slow because of STDOUT ??

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
g...@2ndquadrant.com   www.2ndQuadrant.us


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Reply via email to