Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1ev5T0-00019U-QZ for pgsql-performance@arkaria.postgresql.org; Sun, 11 Mar 2018 18:13:07 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1ev5Sz-0006Am-Gn for pgsql-performance@arkaria.postgresql.org; Sun, 11 Mar 2018 18:13:05 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1ev5Sz-0006Ac-6P for pgsql-performance@lists.postgresql.org; Sun, 11 Mar 2018 18:13:05 +0000 Received: from mail-lf0-x242.google.com ([2a00:1450:4010:c07::242]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1ev5Sr-00072Z-D3 for pgsql-performance@postgresql.org; Sun, 11 Mar 2018 18:13:04 +0000 Received: by mail-lf0-x242.google.com with SMTP id q69-v6so19858743lfi.10 for ; Sun, 11 Mar 2018 11:12:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=asTEG/edWYdU5gs/7U4bjwLKHgCkeW58oAGcXdTqIyE=; b=gyZASyVPqVzdXGp09uS5mA73PWOL7bYjAHCPixjoJUtHd5Mr/gI2j2edLSlCX2cTa6 Ow9k2eOtEEpVdbWekkyD5vkXcmtVQUzeChVccJc/5qxx5060rberaOZvYB9WpUQJXDXF kBmxmSBD332brKteih1geYAKhM8Qa8+8CR7i3KUzyjEKM2zD51QbvMUqpW7bkHQiFSAg EVB+L7TpdKbOzVIk205d2POq+M59XqLQhOpZfIe4It6Ula0Tb9kQCBEfZkvmWK5JpH2X XvX05FnRer1Rq73SBi5rPIBmxUVgcIRPgAsr22r7odH03qwjltLIB+wloLAd6qsgzd9f 3Zeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=asTEG/edWYdU5gs/7U4bjwLKHgCkeW58oAGcXdTqIyE=; b=qTe5BzuTBjIUDyQlV01OvdPDAgaWLTQso2o5BA96AaOaty7xVPzh0QQR+Kg9Ke/mbq KeGbQv5TrPF4G/9iS/8qGW8Wkwtoa+oPw8pV+DmMqFJEHSYyu1VxrtXAFQnr6TYOt96b qgLBEfEXYe0a2/GoebC/jJJPVJiV7SRaMI/j2pHLOscJvU3l6NuYyEsoNzx9lu/6hsoT Y9p+XGBmhJELdnJXe7xXMCvnzQ3hZoLdnpGTOo80NmEfdO/v/OJLHNPyoNvb/Hg4RZLE eDJ9bD8khkA2byFh/XZ4rzPMELisnpp1yqyGTtqZO6naVqMAsjWD0K+Yje6YP01xk84q LisA== X-Gm-Message-State: AElRT7GXIG6gQ3OvYDxPNi4ZJE/dvzL6QxiJVT9EKDEc96Z6abg4UgNa 4z/Uw5C/P6/YdzywIyfRkSSzMzxBzECOf2QdCvm3D3e2PBfwZAXOWQvE59gSmA9Rje786+vurEn SgkaYWwjCG0uvkp8PQznPBUS3BWZ4UxWmAwTUUi7Y/UOFjDq6dgLDZe1PAwqjDE9ixSKjuRhXuk E7dIzksnHiD0KKOBBj X-Google-Smtp-Source: AG47ELtgKwSmuldFaD7co0JhqQ26iMscn6RWnLNYx3C/Fk+Tju+AF/kTLjD2G5P59yNvFZMxglu13w== X-Received: by 10.46.117.12 with SMTP id q12mr3513301ljc.65.1520791974802; Sun, 11 Mar 2018 11:12:54 -0700 (PDT) Received: from [10.137.2.17] (178-78-220-132.customers.ownit.se. [178.78.220.132]) by smtp.gmail.com with ESMTPSA id b27sm1316721ljb.84.2018.03.11.11.12.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 11 Mar 2018 11:12:54 -0700 (PDT) Subject: Re: Memory size To: dangal , pgsql-performance@postgresql.org References: <1520772521740-0.post@n3.nabble.com> <1520789622976-0.post@n3.nabble.com> From: Tomas Vondra Message-ID: <7a228fb5-cf57-851e-e528-2835d628ca8f@2ndquadrant.com> Date: Sun, 11 Mar 2018 19:12:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <1520789622976-0.post@n3.nabble.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 03/11/2018 06:33 PM, dangal wrote: > jeff thank you very much for your time, I tell you, they are the same queries > with the same parameters, I take 3 minutes for example, but I execute it and > it takes me seconds, that's why I suspect it is the shared buffer > The server had 16 GB and we increased it to 24, but I really do not know if > it should continue to increase since they are not our own resources, we have > to ask for them and justify them > It's not very clear if your question is about shared_buffers or amount of RAM in general. In any case, it looks like the performance difference is due to having to do I/O on the first execution, while the second execution gets served from RAM. If that's the case, increasing shared buffers is not going to help, in fact it's going to make matters worse (due to double buffering etc.). You should be able to confirm this by analyzing system metrics, particularly I/O and CPU time. There should be a lot of I/O during the first execution, and almost nothing during the second one. So it seems you need to add more RAM, but it's unclear how much because we don't know what part of the data is regularly accessed (I really doubt it's the whole 750GB). That is something you have to determine by analyzing your workload. All we know is data needed by this query likely fit into RAM, but then get pushed out by other queries after a while. An alternative would be to use better storage system, although that will not give you the same performance, of course. FWIW it's also possible something is going wrong at the hypervisor level (e.g. contention for storage cache used by multiple VMs). It's hard to say, considering you haven't even shared an explain analyze of the queries. Try EXPLAIN (ANALYZE, BUFFERS) both for the slow and fast executions, and show us the results. FWIW you might also read this first: https://wiki.postgresql.org/wiki/Slow_Query_Questions regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services