Re: PG_DUMP very slow because of STDOUT ??
От | Greg Smith |
---|---|
Тема | Re: PG_DUMP very slow because of STDOUT ?? |
Дата | |
Msg-id | 4C3B64FD.3060006@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: PG_DUMP very slow because of STDOUT ?? (Andras Fabian <Fabian@atrada.net>) |
Список | pgsql-general |
Andras Fabian wrote: > - all fast servers show the COPY process as being in the state Rs ("runnable (on run queue)") > - on the still slow server, this process is in 9 out of 10 samples in Ds ("uninterruptible sleep (usually IO)") > I've run into significant performance regressions in PostgreSQL performance due to issues with the Linux scheduler before, specifically when running a single really intensive client program. You might be seeing something similar here. I wrote a reference link heavy blog entry about that at http://notemagnet.blogspot.com/2008/05/pgbench-suffering-with-linux-2623-2626.html you might find useful, one of the batch scheduler tweaks alluded to there might improve things. Regression here in newer kernels are the norm rather than the exception, and given the general lack of quality control in Ubuntu 10.04 I have avoided any performance testing of it yet. I was going to give it six months after release before I even thought about that, in hopes more bugs are squashed, but I'm not optimistic about this distribution for server use at all right now. There's more information about using oprofile at http://wiki.postgresql.org/wiki/Profiling_with_OProfile that might help you dig into the underlying spot it's stuck at. -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.us
В списке pgsql-general по дате отправления: