Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id 6570C1337BC8 for ; Sun, 13 Feb 2011 23:06:19 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 43632-02-8 for ; Mon, 14 Feb 2011 03:06:11 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mail.postgresql.org (Postfix) with ESMTP id 295FF1337C5B for ; Sun, 13 Feb 2011 23:05:40 -0400 (AST) Received: from [192.168.1.6] (mail.highperformancepostgresql.com [71.179.240.8]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0MTvWL-1PgOXU2Jo9-00QkXR; Mon, 14 Feb 2011 04:05:34 +0100 Message-ID: <4D589BFC.5040608@2ndquadrant.com> Date: Sun, 13 Feb 2011 22:05:32 -0500 From: Greg Smith User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Benjamin Krajmalnik CC: Keith Gabryelski , pgsql-admin@postgresql.org Subject: Re: how do you manage postgres 9's postgres process's memory References: <4D579CEE020000250003A936@gw.wicourts.gov> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070201080801060000060600" X-Provags-ID: V02:K0:fiX3tF9Uvuv6v8VnGAOCQKvHlA2U2p7qhTdnOXJ9DrD 4CzC5oBtjtupBL95fQEJEVPabCtxA5V01oerwsAbvMY/xNWaxx dp+M2P9JzHmBqIgJmvPwyZkpA+wLuRNTtL8TyAB9rNGkQ5CYzA E/ucmAdOLnGOfpBcyi9QdBUnqba5G5ImC/xwmBGg+EprpYYiLk rvW/X9Vwb7PvKYQ5PiqFL1dRvVHwodKE8RMy9t4vlw= X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.899 tagged_above=-10 required=5 tests=BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001 X-Spam-Level: X-Archive-Number: 201102/104 X-Sequence-Number: 36743 This is a multi-part message in MIME format. --------------070201080801060000060600 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Benjamin Krajmalnik wrote: > > I ordered some massive servers, and in the course of benchmarking them > following their instructions it exposed apparent hardware issues -- so > the 2 massive servers as well as one of the smaller ones got shipped > back to the supplier for them to check it out. Had I assumed the > servers were performing as the specs on paper indicated, I would have > been in serious trouble a few months down the line as we would have > reached limitations we were not aware of. > As a general statistic on this topic, about 1 out of every 3 servers I come across has a serious problem of this sort. Maybe half of those are just software misconfiguration that can be fixed before deployment, the rest are more serious issues. Nobody should every trust their hardware vendors to get things right, everyone's production schedules are just too tight nowadays relative to how complicated systems are. Benchmarking yourself is the only reasonable defense against this very common problem. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us "PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books --------------070201080801060000060600 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Benjamin Krajmalnik wrote:

I ordered some massive servers, and in the course of benchmarking them following their instructions it exposed apparent hardware issues – so the 2 massive servers as well as one of the smaller ones got shipped back to the supplier for them to check it out.  Had I assumed the servers were performing as the specs on paper indicated, I would have been in serious trouble a few months down the line as we would have reached limitations we were not aware of.


As a general statistic on this topic, about 1 out of every 3 servers I come across has a serious problem of this sort.  Maybe half of those are just software misconfiguration that can be fixed before deployment, the rest are more serious issues.  Nobody should every trust their hardware vendors to get things right, everyone's production schedules are just too tight nowadays relative to how complicated systems are.  Benchmarking yourself is the only reasonable defense against this very common problem.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books
--------------070201080801060000060600--