Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1YMGoC-0002wI-5t for pgsql-performance@arkaria.postgresql.org; Fri, 13 Feb 2015 14:01:28 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1YMGoA-0002sP-ES for pgsql-performance@arkaria.postgresql.org; Fri, 13 Feb 2015 14:01:26 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1YMGo7-0002sG-V6 for pgsql-performance@postgresql.org; Fri, 13 Feb 2015 14:01:24 +0000 Received: from proofpoint1.mail.rice.edu ([128.42.201.100] helo=pp1.rice.edu) by makus.postgresql.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1YMGo3-0002nd-IJ for pgsql-performance@postgresql.org; Fri, 13 Feb 2015 14:01:21 +0000 Received: from pps.filterd (pp1.rice.edu [127.0.0.1]) by pp1.rice.edu (8.14.5/8.14.5) with SMTP id t1DDrDI3014878; Fri, 13 Feb 2015 08:01:15 -0600 Received: from mh3.mail.rice.edu (mh3.mail.rice.edu [128.42.199.10]) by pp1.rice.edu with ESMTP id 1sgbv9s5a6-1; Fri, 13 Feb 2015 08:01:15 -0600 X-Virus-Scanned: by amavis-2.7.0 at mh3.mail.rice.edu, auth channel X-SMTP-Auth: no X-SMTP-Auth: no Received: from aart.rice.edu (aart.rice.edu [168.7.56.48]) by mh3.mail.rice.edu (Postfix) with ESMTP id 94D5D4022B; Fri, 13 Feb 2015 08:01:15 -0600 (CST) Received: by aart.rice.edu (Postfix, from userid 18612) id 8BBBD1007BA; Fri, 13 Feb 2015 08:01:15 -0600 (CST) Date: Fri, 13 Feb 2015 08:01:15 -0600 From: "ktm@rice.edu" To: Nico Sabbi Cc: pgsql-performance@postgresql.org Subject: Re: Configuration tips for very large database Message-ID: <20150213140115.GZ5510@aart.rice.edu> References: <54DD2872.3070603@poste.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54DD2872.3070603@poste.it> User-Agent: Mutt/1.5.20 (2009-12-10) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1502130140 X-Pg-Spam-Score: -4.2 (----) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org On Thu, Feb 12, 2015 at 11:25:54PM +0100, Nico Sabbi wrote: > Hello, > I've been away from postgres for several years, so please forgive > me if I forgot nearly everything:-) > > I've just inherited a database collecting environmental data. > There's a background process continually inserting records (not so > often, to say the truth) and a web interface to query data. > At the moment the record count of the db is 250M and growing all the > time. The 3 main tables have just 3 columns. > > Queries get executed very very slowly, say 20 minutes. The most > evident problem I see is that io wait load is almost always 90+% > while querying data, 30-40% when "idle" (so to say). > Obviously disk access is to blame, but I'm a bit surprised because > the cluster where this db is running is not at all old iron: it's a > vmware VM with 16GB ram, 4cpu 2.2Ghz, 128GB disk (half of which > used). The disk system underlying vmware is quite powerful, this > postgres is the only system that runs slowly in this cluster. > I can increase resources if necessary, but.. > > Even before analyzing queries (that I did) I'd like to know if > someone has already succeeded in running postgres with 200-300M > records with queries running much faster than this. I'd like to > compare the current configuration with a super-optimized one to > identify the parameters that need to be changed. > Any link to a working configuration would be very appreciated. > > Thanks for any help, > Nico > Hi Nico, No one has mentioned the elephant in the room, but a database can be very I/O intensive and you may not be getting the performance you need from your virtual disk running on your VMware disk subsystem. What do IOmeter or other disk performance evaluation software report? Regards, Ken -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance