Hello,
I would appreciate your benchmarks greatly... I think that they would
be useful for many small companies running PostgreSQL since virtual
private servers seem to be very effective solution for organizing many
secure and separate services on single physical machine. We just need
to understand, do we really loose performance or it's insignificant
factor?
Also I would like to hear from smb experienced (you?) about your
unproven theory when you prefer do not run many postgreses in separate
virtual cells having only one cell with single PostgreSQL server.
Intuitively I'd prefer that too, but in practice I have several web
projects that are getting more and more independent from each other,
some of them are secure but some not (even starting from DB level)
since they are not developed anymore. So in this situation I can put
all the old projects (apaches + PostgreSQLs) into separate cells and
forget about problems they can raise (if hacked or smth like that)
since they won't hurt current active projects.
So it would be ideal to know what I pay to OpenVZ for concurrent
resources management for many medium-loaded PostgreSQLs on one
physical machine...
Best regards,
Ivan Zolotukhin
On 6/30/06, Frank Finner <[EMAIL PROTECTED]> wrote:
Hi,
I use this approach both for development and backup servers (with PITR). Everything runs
very smoothly. You should, of course, keep an eye on /proc/user_beancounters and
diskquota to ensure that the engines have enough shared memory, network io (both sockets
and buffer, tcp and "other") and disk space. Stock values are too low.
That__s not a real problem, though, because you can adjust all the values while
running the server, but be careful to adjust shared memory before going in
production, otherwise you might have to restart the database engine.
For production I use several medium loaded OpenVZ machines with apache
webservers, but one dedicated physical machine for the database engine, keeping
one database for each webserver. I did not use one database engine per server,
because I think, that it is more effective to use all its physical memory for
one engine instead of dividing it into parts for several engines. This is an
unproven theory of mine, I did not have enough time to evaluate it.
In principle I found no problems other than giving the OpenVZ server enough ressources. Though I
did not do any speed comparisons "native" vs. "OpenVZ", I could do some
benchmarking next week, if you need some values.
For the PITR OpenVZ PostgreSQL backup server I even copy the WALs etc. using
the base system into /vz/private/... while the OpenVZ database server is down.
As soon as I fire up the OpenVZ database server, it uses the copied stuff while
starting up. Because the OpenVZ server starts with the same IP like the main
database server, there is no need to change anything else while switching from
main server to backup server.
Regards, Frank.
On Fri, 30 Jun 2006 18:37:27 +0400 "Ivan Zolotukhin" <[EMAIL PROTECTED]>
thought long, then sat down and wrote:
> Hello,
>
> Does anybody have experience in running PostgreSQL inside OpenVZ
> (http://openvz.org/) or any other virtual private servers solutions?
> I'm interested in both cases of running single PostgreSQL server and
> multiple PostgreSQLs on one physical machine under relatively high
> (though not IO-limited) load.
>
> Any caveats or limitations of this approach? Any known penalties or
> problems with this tandem?
>
> Best regards,
> Ivan Zolotukhin
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to [EMAIL PROTECTED] so that your
> message can get through to the mailing list cleanly
--
Frank Finner
Invenius - Lösungen mit Linux
Köpfchenstraße 36
57072 Siegen
Telefon: 0271 231 8606 Mail: [EMAIL PROTECTED]
Telefax: 0271 231 8608 Web: http://www.invenius.de
Key fingerprint = 90DF FF40 582E 6D6B BADF 6E6A A74E 67E4 E788 2651
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
