On 07/13/2010 10:35 AM, Andras Fabian wrote:
> 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).
Seemy latest post to Craig.
>
> I hope using vm.zone_reclaim_mode=0 doesn't have other dire consequences :-)
It looks to me that vm.zone_reclaim_mode value is related to NUMA machines that
have "local" memory per node and shouldn't be used at all in your environment.
>
> Andras Fabian
>
> -----Ursprüngliche Nachricht-----
> Von: Greg Smith [mailto:greg@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
>
--
Stephen Clark
NetWolves
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.clark@netwolves.com
www.netwolves.com
