Lists: | pgsql-admin |
---|
From: | daleedom(at)hightowergroup(dot)com (David A(dot) Leedom) |
---|---|
To: | pgsql-admin(at)postgresql(dot)org |
Subject: | Max Number of Databases on a Server. |
Date: | 2002-04-15 11:56:02 |
Message-ID: | 53c1c1b8.0204150356.12a84d67@posting.google.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-admin |
What is the practical limit of Postgres Databases on one typical PC
class Linux server?
If I created 100 separate databases on a Linux Server would this be a
problem? Or is the issue more related to concurrent connections?
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | daleedom(at)hightowergroup(dot)com (David A(dot) Leedom) |
Cc: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: Max Number of Databases on a Server. |
Date: | 2002-04-15 15:19:44 |
Message-ID: | 23245.1018883984@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-admin |
daleedom(at)hightowergroup(dot)com (David A. Leedom) writes:
> If I created 100 separate databases on a Linux Server would this be a
> problem? Or is the issue more related to concurrent connections?
If you're talking about multiple databases served by a single
postmaster, I don't believe it's much of an issue. You might start to
notice performance problems when you got past a few thousands, but
that'd have more to do with kernel performance (slow lookup for many
files in one directory) than Postgres itself.
Concurrent connections is a much more interesting question, but no one
can give you any interesting answers without a lot more assumptions
than "typical Linux server". How much iron is that really, and what
are your concurrent users going to be doing?
regards, tom lane
From: | Jean-Arthur Silve <jeanarthur(at)eurovox(dot)fr> |
---|---|
To: | pgsql-admin(at)postgresql(dot)org |
Subject: | Vacuum blocking... |
Date: | 2002-04-16 07:58:03 |
Message-ID: | 5.1.0.14.0.20020416094730.03a128e0@mail.eurovox.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-admin |
Hello !
I used to run vacuum verbose analyze (vacuumdb -v -a -z) every days.
Everything was ok for months until yesterday !
Usually, this command takes about 1 mn.
Now, vacuum "blocks" on one table (apparently "comptes" table) , without HD
activity, no error message....
avr 15 10:31:27 uranus logger: NOTICE: --Relation comptes--
avr 15 10:31:27 uranus logger: NOTICE: Pages 492: Changed 26, reaped 491,
Empty 0, New 0; Tup 6900: Vac 6229, Keep/VTL 0/0, Crash 0, UnUsed 694,
MinLen 242, MaxLen 698; Re-using: Free/Avail. Space 1946648/1943020;
EndEmpty/Avail. Pages 0/456. CPU 0.04s/0.27u sec.
Then, nothing happens...
Any idea ?
PS : I use 7.0 version
jean-arthur
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jean-Arthur Silve <jeanarthur(at)eurovox(dot)fr> |
Cc: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: Vacuum blocking... |
Date: | 2002-04-16 13:31:52 |
Message-ID: | 11603.1018963912@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-admin |
Jean-Arthur Silve <jeanarthur(at)eurovox(dot)fr> writes:
> Now, vacuum "blocks" on one table (apparently "comptes" table) , without HD
> activity, no error message....
Curious. Do you want to get in there with a debugger and see where it's
looping?
> PS : I use 7.0 version
Hmm ... are you on 7.0.3? There's a known bug in earlier releases that
could perhaps lead to an endless loop in VACUUM.
The simplest answer is probably "past time to update to 7.2.1", anyway.
regards, tom lane