Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id 1CBF6632998 for ; Wed, 21 Jul 2010 12:08:51 -0300 (ADT) 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 78142-01 for ; Wed, 21 Jul 2010 15:08:40 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by mail.postgresql.org (Postfix) with ESMTP id 4FD8B63FF46 for ; Wed, 21 Jul 2010 12:08:40 -0300 (ADT) Received: from [192.168.1.3] (static-71-179-240-8.bltmmd.fios.verizon.net [71.179.240.8]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0LnG25-1PG9r107Z7-00hkkM; Wed, 21 Jul 2010 17:08:38 +0200 Message-ID: <4C470D74.8010509@2ndquadrant.com> Date: Wed, 21 Jul 2010 11:08:36 -0400 From: Greg Smith User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: stanimir petrov CC: pgsql-performance@postgresql.org Subject: Re: tune memory usage for master/slave nodes in cluster References: <609756248.1423.1279716124148.JavaMail.apache@mail71.abv.bg> In-Reply-To: <609756248.1423.1279716124148.JavaMail.apache@mail71.abv.bg> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:aloOyMrWVV0AjGt+10TULwZ36SACT0E8tdT0JuC0Iha Mu08gKtekqifkoMwswIDVJKuEzasiW1MIsaaL8eUdA9RZYFbA2 RIbimE5Bc2cWOuSrw9s9bdNXPV5kdn/hDlaxnQJgYyML5WLelG IKdLgIUysfYzTyw0D9+pHr2wMYnwBKknMilv92vCGK5RywsFE1 KCxRUrc1s6LDvdF6wy0XgO7/+DaqMkopdD7qQjM54Y= X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-0.001 tagged_above=-10 required=5 tests=BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001 X-Spam-Level: X-Archive-Number: 201007/303 X-Sequence-Number: 39692 stanimir petrov wrote: > Now the servers are dual core CPU 2.6 with 1.7 GB RAM and i standart > disk. (the small instance from AWS) You're never going to be able to tune for writing data fast on a AWS environment; there just isn't enough disk throughput available. If this application really does take off the way you expect it to, don't be surprised to find you have to move it to real hardware to keep up. Dedicated database servers tend to have tens of disks in them to keep up with the sort of load you're expecting, and you just can't get that in a cloud environment. You can do some work to improve I/O using multiple storage instances; http://blog.endpoint.com/2010/02/postgresql-ec2-ebs-raid0-snapshot.html is a good introduction to that. The basic tuning advice you're looking for is available at http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server If you are trying to get faster writes out of AWS hardware, you may have to turn off synchronous_commit to accomplish that. That has some potential lost transaction downsides, but simple disks just can't write data that fast so it may be the only way to make this work well. -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.us