DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=ymail.com;
 h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
 b=2Hp1z5GVhtfKOMgp0lbYeIiQRlLarNjQdNh23BB9St1FRc70BYSyetbk4GVE/MGPcwH5fppNDNONg15k8r+iKW2oABYLXzljvLoEl2wieCe6uPZXhmGUlbEFjxNYEKySv/uqxvIDsNt7a2Y6eHFXe88D905Sw2LoOhNr49RT+PI=;
References: <1377778443804-5768917.post@n5.nabble.com>
 <521F61B9.1000709@archonet.com> <521F63DD.3050301@commandprompt.com>
 <1377792804612-5768951.post@n5.nabble.com>
Message-ID: <1377960241.19370.YahooMailNeo@web162901.mail.bf1.yahoo.com>
Date: Sat, 31 Aug 2013 07:44:01 -0700 (PDT)
From: Kevin Grittner <kgrittn@ymail.com>
Reply-To: Kevin Grittner <kgrittn@ymail.com>
Subject: Re: How clustering for scale out works in PostgreSQL
To: bsreejithin <bsreejithin@gmail.com>,
 "pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
In-Reply-To: <1377792804612-5768951.post@n5.nabble.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

bsreejithin <bsreejithin@gmail.com> wrote:

> What I posted is about a new setup that's going to come
> up..Discussions are on whether to setup DB cluster to handle 1000
> concurrent users.

I previously worked for Wisconsin Courts, where we had a single
server which handled about 3000 web users collectively generating
hundreds of web hits per second generating thousands of queries per
second, while at the same time functioning as a replication target
from 80 sources sending about 20 transactions per second which
modified data (many having a large number of DML statements per
transaction) against a 3 TB database.=A0 The same machine also hosted
a transaction repository for all modifications to the database,
indexed for audit reports and ad hoc queries; that was another 3
TB.=A0 Each of these was running on a 40-drive RAID.

Shortly before I left we upgraded from a machine with 16 cores and
256 GB RAM to one with 32 cores and 512 GB RAM, because there is
constant growth in both database size and load.=A0 Performance was
still good on the smaller machine, but monitoring showed we were
approaching saturation.=A0 We had started to see some performance
degradation on the old machine, but were able to buy time by
reducing the size of the web connection pool (in the Java
application code) from 65 to 35.=A0 Testing different connection pool
sizes showed that pool size to be optimal for our workload on that
machine; your ideal pool size can only be determined through
testing.

You can poke around in this application here, if you like:
http://wcca.wicourts.gov/

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


--=20
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance