Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Xp3W1-0005iV-QH for pgsql-performance@arkaria.postgresql.org; Thu, 13 Nov 2014 23:09:25 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Xp3W1-0005mH-9B for pgsql-performance@arkaria.postgresql.org; Thu, 13 Nov 2014 23:09:25 +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 1Xp3W0-0005mA-34 for pgsql-performance@postgresql.org; Thu, 13 Nov 2014 23:09:24 +0000 Received: from mail-ig0-f180.google.com ([209.85.213.180]) by makus.postgresql.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1Xp3Vw-0002sz-Pe for pgsql-performance@postgresql.org; Thu, 13 Nov 2014 23:09:22 +0000 Received: by mail-ig0-f180.google.com with SMTP id h15so542993igd.7 for ; Thu, 13 Nov 2014 15:09:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=2CAytG+fq1rkzdIvwUaepNET2xS8Wiw3XG9B76Ah2YQ=; b=gtR64fxitknNc+QPJjXZcT5SNGADj5abghri3TnA+lDHRvtco+U900nNSAZs7dPPGs VxurHBxxMGmwsQspQKK1+U0hePChb0bECeIQpRqSXqOzn1iwa8ODgB/C7xWMPAHAj7Mm JjydJCnZHs0QntOincaHOhSAfKNCOOXETzQs9WCIBogoOBxYINQEaZPu55CtlpgwUKs4 LXWoLlpUr4DfxLeI9GEj4RhTuI7FnYH88O6G7tWUrCi5wo4us2DYsZ3qz6ZdBegWQi76 plIAwJithyOapc8isgqnP1SPlU7kQZWNpfZ5FASlXXY35iBqwvuOB7IAKGSXeveJ0Uv6 DWNQ== X-Gm-Message-State: ALoCoQnMVX9rsrRKtJ+9UvTlnYKgptAQ66IK7GcHqx0hhcH3oaLODlJ4W+DGPaT9mazkeaHpSBUu X-Received: by 10.51.17.104 with SMTP id gd8mr2093821igd.21.1415920159669; Thu, 13 Nov 2014 15:09:19 -0800 (PST) Received: from kevins-MacBook-Pro.local ([50.243.150.94]) by mx.google.com with ESMTPSA id ii3sm1617296igb.1.2014.11.13.15.09.18 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Nov 2014 15:09:19 -0800 (PST) Message-ID: <54653A1E.3050805@consistentstate.com> Date: Thu, 13 Nov 2014 16:09:18 -0700 From: CS DBA User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Increased shared_buffer setting = lower hit ratio ? Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -2.6 (--) 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 All; We have a large db server with 128GB of ram running complex functions. with the server set to have the following we were seeing a somewhat low hit ratio and lots of temp buffers shared_buffers = 18GB work_mem = 75MB effective_cache_size = 105GB checkpoint_segments = 128 when we increased the values to these not only did the hit ratio drop but query times are now longer as well: shared_buffers = 28GB work_mem = 150MB effective_cache_size = 105GB checkpoint_segments = 256 This does not seem to make sense to me, anyone have any thoughts on why more memory resources would cause worse performance? Thanks in advance -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance