Received: from localhost (unknown [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id 81F632E021B for ; Wed, 5 Mar 2008 11:03:06 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024) with ESMTP id 69099-08 for ; Wed, 5 Mar 2008 11:02:45 -0400 (AST) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.5 Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.182]) by postgresql.org (Postfix) with ESMTP id AD2332E00FB for ; Wed, 5 Mar 2008 11:02:52 -0400 (AST) Received: by el-out-1112.google.com with SMTP id z25so2058929ele.0 for ; Wed, 05 Mar 2008 07:02:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=4Vec8RpA2wSswIWTFez8NUhmPtYcq+OpluM8n7Em1F0=; b=tfWsGqkKP/mcvEbbwO+ALGPkZnVTd3C8YKADdqKcDjhOPOofqNL/2r1FgbItMrYSXV1dvoT1Xi1eRc0O5AaSy9IfxLyAACwuiAoRya7+/6qXEZz74hHKJjRD6IMv7kxJCXLhivjjr22dx2TvjJaJsZaNhFGYBzDDZPIw9WEIcI4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NXe2HY6rZiDmJstSNY10/8Y4vlVkaonEBbSSG+ftGbvHQ/Eh+1Nt425HuyJYvCitOhQZgvTuzJWkqPMzSDsyVIfIrXHyf5a02BJWPKRp/uz5JriBovwOMNrIFzY6lewY53mGiqnIP93WKgtubfeaf08HEMfKCZ9tPu8U1aLQybU= Received: by 10.114.53.1 with SMTP id b1mr4523209waa.134.1204728973757; Wed, 05 Mar 2008 06:56:13 -0800 (PST) Received: by 10.114.79.1 with HTTP; Wed, 5 Mar 2008 06:56:11 -0800 (PST) Message-ID: <751e56400803050656s276cc68cmd677af9dfaafea2c@mail.gmail.com> Date: Wed, 5 Mar 2008 17:56:11 +0300 From: "Ivan Zolotukhin" To: "Bill Moran" Subject: Re: PostgreSQL performance on a virtual host Cc: "Moritz Onken" , pgsql-performance@postgresql.org In-Reply-To: <20080305094010.76853e07.wmoran@collaborativefusion.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1204645380.2406.18.camel@localhost6.localdomain6> <70C3ABFE-7D91-48B8-8613-C562CB0FB912@houseofdesign.de> <751e56400803050626i50b1a696k15a8888b4ef025b4@mail.gmail.com> <20080305094010.76853e07.wmoran@collaborativefusion.com> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200803/77 X-Sequence-Number: 29031 Hello, On Wed, Mar 5, 2008 at 5:40 PM, Bill Moran wrote: > In response to "Ivan Zolotukhin" : > > > > > We had a bad experience with PostgreSQL running in OpenVZ (year and a > > half year ago): OpenVZ kernel killed postmaster with strange signals > > from time to time, failcounters of OpenVZ did not worked as expected > > in this moments, PostgreSQL fighted for the disk with applications in > > other virtual cells, no one from OpenVZ forums was able to help me > > with these issues. So this experience was really dissapointing; since > > then we use only dedicated systems without kernels patched for > > virtualization. > > If your database is busy enough that it's stressing the hardware on a > single machine, it's not going to do any better in a VM. Sounds to me like > you were already pushing the limits of the IO capability of that machine ... > it's not OpenVZ's fault that it can't make more IO bandwidth available. The problem actually was that PostgreSQL worked closely to some kernel limits and kernel simply killed it sometimes without counting that in corresponding failcounters. And there was no existing OpenVZ documentation to debug these issues which I think is unacceptable. Workload (incl. IO load) was moderate, nothing extremal. I don't like when system kills my PostgreSQL without even telling me why. Apart from that I think that administrator should be able to decide himself whether load is high enough to stop some process for it not to interfere with other virtual cells. OpenVZ with its documentation and experts on dedicated forum did not provide such instruments at that time. I would be satisfied with OpenVZ if I'd be able to tell the system not to kill my PostgreSQL whatever happens, but I couldn't. So I simply switched to something more reliable. > > On Wed, Mar 5, 2008 at 11:54 AM, Moritz Onken wrote: > > > We have very good experiences with openVZ as virtualizer. > > > Since it's not a para virtualization like xen it's very fast. Almost > > > as fast as the host. > > > > > > www.openvz.org > > > > > > Am 04.03.2008 um 16:43 schrieb Theo Kramer: > > > > > > > > > > > > > Hi > > > > > > > > We are thinking of running a PostgreSQL instance on a virtual host > > > > under > > > > Xen. > > > > > > > > Any thoughts for/against running PostgreSQL on a virtual host would be > > > > much appreciated. > > > > > > > > -- > > > > Regards > > > > Theo > > > > > > > > > > > > -- > > > > Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org > > > > ) > > > > To make changes to your Subscription: > > > > http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.org&extra=pgsql-performance > > > > > > > > > -- > > > Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) > > > To make changes to your subscription: > > > http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.org&extra=pgsql-performance > > > > > > > -- > > Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) > > To make changes to your subscription: > > http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.org&extra=pgsql-performance > > > -- > Bill Moran > Collaborative Fusion Inc. > http://people.collaborativefusion.com/~wmoran/ > > wmoran@collaborativefusion.com > Phone: 412-422-3463x4023 > > **************************************************************** > IMPORTANT: This message contains confidential information and is > intended only for the individual named. If the reader of this > message is not an intended recipient (or the individual > responsible for the delivery of this message to an intended > recipient), please be advised that any re-use, dissemination, > distribution or copying of this message is prohibited. Please > notify the sender immediately by e-mail if you have received > this e-mail by mistake and delete this e-mail from your system. > E-mail transmission cannot be guaranteed to be secure or > error-free as information could be intercepted, corrupted, lost, > destroyed, arrive late or incomplete, or contain viruses. The > sender therefore does not accept liability for any errors or > omissions in the contents of this message, which arise as a > result of e-mail transmission. > **************************************************************** >