mentioned in the LKML thread).
Andras Fabian
-Ursprüngliche Nachricht-
Von: Craig Ringer [mailto:cr...@postnewspapers.com.au]
Gesendet: Mittwoch, 14. Juli 2010 05:11
An: Andras Fabian
Cc: pgsql-general@postgresql.org
Betreff: Re: AW: AW: AW: AW: AW: [GENERAL] PG_DUMP very slow because of STDOUT
untu ...
By the way, would it maybe make sense, to put this information in the
PostgreSQL Documentation ... as a kind of cautionary warning? Could make life
for some admins easier in the future (especially if Ubuntu or other
distributions bring different settings here).
Andras Fabian
-Urs
(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. J
omorrow I will see how my nightly backup runs with this setting.
Andras fabian
-Ursprüngliche Nachricht-
Von: Craig Ringer [mailto:cr...@postnewspapers.com.au]
Gesendet: Dienstag, 13. Juli 2010 14:11
An: Andras Fabian
Cc: pgsql-general@postgresql.org
Betreff: Re: AW: AW: AW: AW: [GENE
ulation, but still.
I now also looked at the stack, before the congestion_wait. There are some
"interesting" calls leading to it. Like "shrink_list", "zone_reclaim" ... after
the call of "get_page_from_freelist". Sounds like some heavy memory juggling
is not always present in PS ... (finished after 6 1/2 minutes
instead the optimum around 2 1/2).
Something very fishy about the memory manager
Andras Fabian
-Ursprüngliche Nachricht-
Von: Andras Fabian
Gesendet: Dienstag, 13. Juli 2010 13:35
An: 'Craig Ringer'
Cc: pgsql-gene
of 16) ... but still,
they manage to gracefully give back RAM to whoever needs it (i.e. the backup
process with its COPY-to-STDOU or others). Well, the difference is of course 6
Kernel versions (old machine 2.6.26 ... new machin 2.6.32) ... or who knows
what kernel settings ...
Andras Fabian
e a way to influence the memory manager Linux in a way, that it
behaves a bit more conservative (or just different in a positive way)?
Andras Fabian
-Ursprüngliche Nachricht-
Von: Craig Ringer [mailto:cr...@postnewspapers.com.au]
Gesendet: Dienstag, 13. Juli 2010 12:51
An: Andras Fabian
Cc: pgsql-
??? And can/could
I control its behavior at all?? (or would it be a thing, which can only be
controlled from C-Code ... which would fall back to PostgreSQL as the
initiator).
Andras Fabian
-Ursprüngliche Nachricht-
Von: Craig Ringer [mailto:cr...@postnewspapers.com.au]
Gesendet: Dienstag
s.
Now I "only" who and why is running out, and how I can prevent that. Could
there be some extremely big STDOUT buffering in play
I will need to do some more investigation. And thanks for your very good
pointers which help me to narrow the focus down!
Andras Fabian
-Ursprü
-STDOUT. On a "slow" machine, those counters - but always only one of
them - got some really big numbers while the process was stuck in
congestion_wait.
Andras Fabian
-Ursprüngliche Nachricht-
Von: Craig Ringer [mailto:cr...@postnewspapers.com.au]
Gesendet: Dienstag, 13. Juli 201
could go against the file system / drive argument. My
initial tests, where I did a COPY-to-FILE, I have never head problems (only
COPY-to-STDOUT gives them).
Well, I will try to gather some more information with your other hints (quite a
lot of stuff - and one learns a lot
is take only a bit over 2 minutes to complete ... and although, one sees
congestion_wait in PS from time to time, it is not dominant, and there are
other EXT4 or IO related function shown. ... But maybe this mini-experiment is
lacking some important steps, that are in the path of a COPY-to-STDOUT
te
activity). The drive, from which the reads come (the one, where PG-s data files
are ... it is the 8-disk RAID 10), has a little bit more activity (utilization
6-8%) but this data is also - concurrently - in use by some apps reading from
the DB (just, normal traffic on the DB).
Andras Fabia
u for
your idea ... this is exactly the way I try to approach the problem, by making
some theories and trying to prove or disapprove them :-)
Now I will try to further investigate along the tips from Craig and Greg.
Andras Fabian
-Ursprüngliche Nachricht-
Von: Scott Marlowe [mailto:scot
d :-).
And yes, now I see a reboot as a possible "Fix", but that would not ensure me,
that the problem will not resurface. So, for the time being, I will leave my
current second production server as is ... so I can further narrow down the
potential reasons of this strange STDOUT slow down
installed - next and identical - new
servers).
Andras Fabian
-Ursprüngliche Nachricht-
Von: Tom Lane [mailto:t...@sss.pgh.pa.us]
Gesendet: Freitag, 9. Juli 2010 15:39
An: Andras Fabian
Cc: pgsql-general@postgresql.org
Betreff: Re: [GENERAL] PG_DUMP very slow because of STDOUT ??
Andras
hing like that to "tweak"
it on the fly
Andras Fabian
Von: Craig Ringer [cr...@postnewspapers.com.au]
Gesendet: Freitag, 9. Juli 2010 22:11
An: Tom Lane
Cc: Andras Fabian; pgsql-general@postgresql.org
Betreff: Re: [GENERAL] PG_DUMP very slow becau
ideas until then ... (or have experience this
or similar weirdness too).
Andras Fabian
-Ursprüngliche Nachricht-
Von: Tom Lane [mailto:t...@sss.pgh.pa.us]
Gesendet: Freitag, 9. Juli 2010 15:39
An: Andras Fabian
Cc: pgsql-general@postgresql.org
Betreff: Re: [GENERAL] PG_DUMP very slow
disks for Data only, and XLOG/Backup/OS on a second RAID 1
with 2 disks, with hardware raid controller and battery backed cache (so,
obviously, this machine should be faster than the old one)
Can someone shed some light on this STDOUT madness? Or give me some
directions/hints in which I
20 matches
Mail list logo
