Re: PG_DUMP very slow because of STDOUT ??
От | Andras Fabian |
---|---|
Тема | Re: PG_DUMP very slow because of STDOUT ?? |
Дата | |
Msg-id | B1A1AD14D5F9D647BD2A00988C53B8220ACA307B@atradaex03.nbg.atrada.net обсуждение исходный текст |
Ответ на | Re: PG_DUMP very slow because of STDOUT ?? (Scott Marlowe <scott.marlowe@gmail.com>) |
Ответы |
Re: PG_DUMP very slow because of STDOUT ??
|
Список | pgsql-general |
Hi Scott, No, we didn't have a kernel update (it is still the stock Ubuntu 10.04 Server kernel ... 2.6.32.2). And in the meantime -this morning - I have discovered, that the rebooted server is again slowing down! It is not at the level of the not-rebooted-server(about 45 mins for the 3 Gig file)... it "only" needs 22 minutes, but it is already quite a bit away fromthe optimum of 3 minutes (or less). So, definitely, something is "deteriorating" in the system ... And I also did dome readings with iostat -xd 5 ... And the target drive to which the output of the STDOUT is directed isbelow 1% utilization (mostly around 0.2 - 0.4%) with rare "peaks around 2-3% when it does a little bit more. And this ismaybe one of the interesting observations. It seems to periodically "flush" a bit more out, just to fall asleep again (withminimum write activity). The drive, from which the reads come (the one, where PG-s data files are ... it is the 8-diskRAID 10), has a little bit more activity (utilization 6-8%) but this data is also - concurrently - in use by some appsreading from the DB (just, normal traffic on the DB). Andras Fabian -----Ursprüngliche Nachricht----- Von: Scott Marlowe [mailto:scott.marlowe@gmail.com] Gesendet: Dienstag, 13. Juli 2010 09:45 An: Andras Fabian Cc: Tom Lane; pgsql-general@postgresql.org Betreff: Re: [GENERAL] PG_DUMP very slow because of STDOUT ?? On Tue, Jul 13, 2010 at 12:31 AM, Andras Fabian <Fabian@atrada.net> wrote: > Hi Scott, > > Although I can't guarantee for 100% that there was no RAID rebuild at some point, I am almost sure that it wasn't the case.Two machines - the ones which were already in production - exhibited this problem. Both of them were already up forsome weeks. Now, the reboot rather "fixed" one of them instead of making it worse (as your theory goes this way) the problem"disappeared" (but I don't know for how long). Now, only one of the production machines has the issue ... the onewhich wasn't rebooted. Strange, strange. Nevertheless thank you for your idea ... this is exactly the way I try to approachthe 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. Was there maybe a kernel update that hadn't been applied by reboot?
В списке pgsql-general по дате отправления: