Re: PostgreSQL and OpenVZ

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 <postgresql(at)finner(dot)de> 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" <ivan(dot)zolotukhin(at)gmail(dot)com> 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 majordomo(at)postgresql(dot)org 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: frank(dot)finner(at)invenius(dot)de
> Telefax: 0271 231 8608 Web: http://www.invenius.de
> Key fingerprint = 90DF FF40 582E 6D6B BADF 6E6A A74E 67E4 E788 2651
>
>
>