Can you not nice the dump process to free up resources during the dump? Of
course this will not free up any locks, and will make them hang around longer
as the dump is slowed down.
Brent Wood
GIS/DBA consultant
NIWA
+64 (4) 4 386-0300
From: pgsql-general
This message has been digitally signed by the sender.
Re___GENERAL__CPU_move.eml
Description: Binary data
-
Hi-Tech Gears Ltd, Gurgaon, India
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.
Am 26.11.2011 19:18, schrieb Carlos Henrique Reimer:
> Hi,
>
> We're planning to move our postgreSQL database from one CPU box to
> another box.
>
> I'm considering an alternative procedure for the move as the standard
> one (pg_dump from the old, copy dump to the new box, psql to restore in
> th
On Saturday, November 26, 2011 10:18:56 AM Carlos Henrique Reimer wrote:
> Hi,
>
> We're planning to move our postgreSQL database from one CPU box to another
> box.
>
> I'm considering an alternative procedure for the move as the standard one
> (pg_dump from the old, copy dump to the new box, psq
Josh,
However, the two extra cores (even if slower), will greatly help if you
> have any kind of concurrency.
>
as much as I understand with running Postgres in the default configuration,
there *will* be concurrency, without an "if" ?
I am thinking of the background writer, the autovacuum proces
On Mon, 3 Dec 2007, Joshua D. Drake wrote:
Well honestly, with how cheap you can get a quad core from Intel... I
say do that
Exactly, the budget single processor configuration to beat in server land
right now is the Xeon X3210. The frequency of the cores is a little on
the low side, so indi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 03 Dec 2007 22:30:58 -0600
Ron Johnson <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 12/03/07 21:27, Joshua D. Drake wrote:
> > Uwe C. Schroeder wrote:
> >> On Monday 03 December 2007, Tom Allison wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/03/07 21:27, Joshua D. Drake wrote:
> Uwe C. Schroeder wrote:
>> On Monday 03 December 2007, Tom Allison wrote:
>>> is there much of a difference in performance between a XEON, dual
>>> core from intel and a dual core AMD 64 CPU?
>
> Well honest
Uwe C. Schroeder wrote:
On Monday 03 December 2007, Tom Allison wrote:
is there much of a difference in performance between a XEON, dual
core from intel and a dual core AMD 64 CPU?
Well honestly, with how cheap you can get a quad core from Intel... I
say do that :). The general difference bet
On Monday 03 December 2007, Tom Allison wrote:
> is there much of a difference in performance between a XEON, dual
> core from intel and a dual core AMD 64 CPU?
>
> I need a bit of an upgrade and am not sure which, if any, have a
> significant advantage for postgres databases.
>
Personally I've ne
Hi Max,
To find out what is causing the big load you could also try to use 'ATOP'
which can be found at http://www.atcomputing.nl/atop. This tool shows more
(accurate) information than the regular TOP.
There are also some kernel patches available which, when applied to your
kernel, even show more
On Thu, 23 Aug 2007 12:24:32 +0400, Hannes Dorbath
<[EMAIL PROTECTED]> wrote:
On 23.08.2007 11:04, Max Zorloff wrote:
When one postgres process waits for lock to release does it use any cpu?
And also, when apache waits for query to finish, does it use cpu?
No, but are you sure what you see
On 23.08.2007 11:04, Max Zorloff wrote:
When one postgres process waits for lock to release does it use any cpu?
And also, when apache waits for query to finish, does it use cpu?
No, but are you sure what you see is not i/o wait? What values does top
display in the %wa columns in the CPU rows?
On Thu, 23 Aug 2007 08:29:03 +0400, Tom Lane <[EMAIL PROTECTED]> wrote:
"Max Zorloff" <[EMAIL PROTECTED]> writes:
... The problem is that after the number of concurrent users rises to
100, CPU becomes almost 100% loaded. How do I find out what's hogging
the
CPU?
'top' shows demon using 8%
Hi Max,
To find out what is causing the big load you could also try to use 'ATOP'
which can be found at http://www.atcomputing.nl/atop. This tool shows more
(accurate) information than the regular TOP.
There are also some kernel patches available which, when applied to your
kernel, even show more
"Max Zorloff" <[EMAIL PROTECTED]> writes:
> ... The problem is that after the number of concurrent users rises to
> 100, CPU becomes almost 100% loaded. How do I find out what's hogging the
> CPU?
> 'top' shows demon using 8% cpu on top, and some amount of postgres
> processes each using 2%
"Thomas F. O'Connell" <[EMAIL PROTECTED]> writes:
> Honestly, I'd prefer to see pg_autovacuum improved to do O(n) rather
> than O(n^2) table activity. At this point, though, I'm probably not
> too likely to have much time to hack pg_autovacuum before 8.1 is
> released, although if it doesn't
I was usleeping in tiny increments in each iteration of the loop. I
didn't try break it into iterative groups like this.
Honestly, I'd prefer to see pg_autovacuum improved to do O(n) rather
than O(n^2) table activity. At this point, though, I'm probably not
too likely to have much time to h
--- "Thomas F. O'Connell" <[EMAIL PROTECTED]> wrote:
> Phil,
>
> If you complete this patch, I'm very interested to see it.
>
> I think I'm the person Matthew is talking about who inserted a sleep
>
> value. Because of the sheer number of tables involved, even small
> values of sleep cause
Phil,
If you complete this patch, I'm very interested to see it.
I think I'm the person Matthew is talking about who inserted a sleep
value. Because of the sheer number of tables involved, even small
values of sleep caused pg_autovacuum to iterate too slowly over its
table lists to be of u
Phil Endecott <[EMAIL PROTECTED]> writes:
> (Incidentally, I have also found that the indexes on my pg_attributes
> table were taking up over half a gigabyte, which came down to less than
> 40 megs after reindexing them. Is there a case for having autovacuum
> also call reindex?)
Lots of temp
Matthew T. O'Connor wrote:
The integrated version
of autovacuum that didn't make the cut before 8.0 avoids this problem
since the autovacuum data is stored in the database.
What is the status of this? Is it something that will be included in
8.1 or 8.0.n? I might be able to patch the curren
Phil Endecott wrote:
> Matthew T. O'Connor wrote:
> > The integrated version
> > of autovacuum that didn't make the cut before 8.0 avoids this problem
> > since the autovacuum data is stored in the database.
>
> What is the status of this? Is it something that will be included in
> 8.1 or 8.0.
Phil Endecott wrote:
Matthew T. O'Connor wrote:
The integrated version of autovacuum that didn't make the cut before
8.0 avoids this problem since the autovacuum data is stored in the
database.
What is the status of this? Is it something that will be included in
8.1 or 8.0.n? I might be
Phil Endecott wrote:
Matthew T. O'Connor wrote:
Indeed you have. I have head a few similar reports but perhaps none
as bad as yours. One person put a small sleep value so that it
doesn't spin so tight. You could also just up the sleep delay so
that it doesn't do this work quite so often.
Matthew T. O'Connor wrote:
Phil Endecott wrote:
> Could it be that there is some code in autovacuum that is O(n^2) in
> the number of tables?
Browsing the code using webcvs, I have found this:
for (j = 0; j < PQntuples(res); j++)
{
tbl_elem = DLGetHead(dbs->table_list);
while (tbl_elem
Phil Endecott wrote:
Following up on my own post from last night:
> Could it be that there is some code in autovacuum that is O(n^2) in
> the number of tables?
Browsing the code using webcvs, I have found this:
for (j = 0; j < PQntuples(res); j++)
{
tbl_elem = DLGetHead(dbs->table_list);
Following up on my own post from last night:
> Could it be that there is some code in autovacuum that is O(n^2) in
> the number of tables?
Browsing the code using webcvs, I have found this:
for (j = 0; j < PQntuples(res); j++)
{
tbl_elem = DLGetHead(dbs->table_list);
while (tbl_
Quoth [EMAIL PROTECTED] ("Mark Cubitt"):
> is there a way of finding out which table is using a certain amount of CPU
> power?
That doesn't entirely make sense.
Tables normally use up disk space.
What consumes CPU power is the computation of queries, and, for big,
expensive queries, it is pretty
On Fri, 27 Oct 2000, Vilson farias wrote:
> I've been using Postgres in a Pentium 75Mhz, Linux RedHat 6.2, 32Mb.
>
>Every big query I execute uses too much cpu (more than 90%).
>
>I start postgres with these params: su -l postgres -c
> '/usr/bin/postmaster -B 2048 -i -D "/home/post
On Fri, Oct 27, 2000 at 07:12:57PM -0200, Vilson farias wrote:
>I start postgres with these params: su -l postgres -c
> '/usr/bin/postmaster -B 2048 -i -D "/home/postgres/data"' &.
Try starting postmaster with 'nice':
nice /usr/bin/postmaster -B 2048 -i -D /home/postgres/data &
--
Igor Ro
* Vilson farias <[EMAIL PROTECTED]> [001027 21:38] wrote:
> Greetings,
>
> I've been using Postgres in a Pentium 75Mhz, Linux RedHat 6.2, 32Mb.
>
>Every big query I execute uses too much cpu (more than 90%).
>
>I start postgres with these params: su -l postgres -c
> '/usr/bin/postma
32 matches
Mail list logo
