Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c1KeD-0008Sq-Ix for pgsql-performance@arkaria.postgresql.org; Mon, 31 Oct 2016 22:01:41 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1c1KeD-00030w-45 for pgsql-performance@arkaria.postgresql.org; Mon, 31 Oct 2016 22:01:41 +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.84_2) (envelope-from ) id 1c1KcY-000176-1o for pgsql-performance@postgresql.org; Mon, 31 Oct 2016 21:59:58 +0000 Received: from mail-wm0-x234.google.com ([2a00:1450:400c:c09::234]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1c1KcU-00051k-JR for pgsql-performance@postgresql.org; Mon, 31 Oct 2016 21:59:57 +0000 Received: by mail-wm0-x234.google.com with SMTP id n67so254600551wme.1 for ; Mon, 31 Oct 2016 14:59:54 -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-transfer-encoding; bh=GFHaBsHophxJjHBXMAsANhBQSP0O/q53fEj+yQF7Kvo=; b=IcC4pOR8rOIkAZhkx8UAhPyiMMs+p4HufuNQCaUK6y1SmS5pA4wFQjkKv/NXBsZEK4 iwgzZriNdQgnItLaHebkpjztNIft1229tlCd8Rxt06hgulDHaROKH6O5V6TNfUOiXGaC cAW30YlIakSdFzuIjW11BebZjidZhlzxvHZEieE3eJTluQbzbvufXXqwIYbkYptu1r3j 3Q+qC28CQFgs5Xfscnua/XGKJIRh3DoghktuTZadtklKv7bEh8XK56MPm3/+Ph+nNvCX bvRp5gl/PZ4Yyc0jFjTnZ0v/9XVIRHlNEHultBbw7YcW7uFhyRZlTP4Q/rFKTUDs7knu cg8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=GFHaBsHophxJjHBXMAsANhBQSP0O/q53fEj+yQF7Kvo=; b=Rbzoq0PY3mmMC4Xj8clMBpn0nMUcmrIzhZGTNMfnferhfWBfEXIOXDtOscRWf8p6Nt HmWCOKGgrY7eZW0zVs6cmWhP+hCoZSLb3I008MCTJZ5MuMu5Puj1zQigUiz8PyUn4yKI 92qBkx1g/OvLU8eQ4E4TR0O3DC70YMfZOIvMtZ+sQ9sS0N6vhkD6bpB3iFfCeldbNRlA 6klQb8RMTL6++kDM43cEito36QDqq9or+m3UXzdJCJt5FX/e1WgVTARGk74fGsvXcNK2 t3S9ZAoIbYEnRcvRxo62qAgkwfgY/wUAVfessqQFkeY68GCRPm07cs033girQeFQWV+5 cmDQ== X-Gm-Message-State: ABUngvf3RbjhW/PtWLlsQmg+qPn5/zM5tijjfnIbpxJPi+Fc5SIZ6766qrOFCShDk/mPM+F5e5B1GA2++0NgzQ2x72Tz2xwRU2MrRKxln7kSzY31mOH1RdhLwoiBlMKIsUvAQTV3JfXjp56niIr8zcie5hHCEO/Nhe8xXNEbUPcdKh0JFFBXXmjVwe/bkMg7E3y2D99X6ale/ECeXw== X-Received: by 10.194.201.227 with SMTP id kd3mr29586066wjc.74.1477951193330; Mon, 31 Oct 2016 14:59:53 -0700 (PDT) Received: from [10.137.2.17] (ip-89-177-44-58.net.upcbroadband.cz. [89.177.44.58]) by smtp.gmail.com with ESMTPSA id f194sm27092056wmg.12.2016.10.31.14.59.52 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Oct 2016 14:59:52 -0700 (PDT) Subject: Re: Tuning Checkpoints To: pgsql-performance@postgresql.org References: From: Tomas Vondra Message-ID: Date: Mon, 31 Oct 2016 22:59:50 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:46.0) Gecko/20100101 Thunderbird/46.0a2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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 On 10/31/2016 08:19 PM, Andre Henry wrote: > My PG 9.4.5 server runs on Amazon RDS some times of the day we have a > lot of checkpoints really close (less than 1 minute apart, see logs > below) and we are trying to tune the DB to minimize the impact of the > checkpoint or reduce the number of checkpoints. > > Server Stats > > · Instance Type db.r3.4xl > > • 16 vCPUs 122GB of RAM > > • PostgreSQL 9.4.5 on x86_64-unknown-linux-gnu, compiled by gcc > (GCC) 4.8.2 20140120 (Red Hat 4.8.2-16), 64-bit > > > > Some PG Stats > > • Shared Buffers = 31427608kB > > • Checkpoint Segments = 64 > > • Checkpoint completion target = .9 > > • Rest of the configuration is below > > > > Things we are doing > > • We have a huge table where each row is over 1kB and its very > busy. We are splitting that into multiple tables especially the one json > field that making it large. > > > > Questions > > • Each checkpoint log writes out the following checkpoint > complete: wrote 166481 buffers (4.2%); 0 transaction log file(s) added, > 0 removed, 64 recycled; write=32.441 s, sync=0.050 s, total=32.550 s; > sync files=274, longest=0.049 s, average=0.000 s > OK, each checkpoint has to write all dirty data from checkpoints. You have ~170k buffers worth of dirty data, i.e. ~1.3GB. > • What does buffers mean? How do I find out how much RAM that is > equivalent to? > Buffer holds 8kB of data, which is the "chunk" of data files. > • Based on my RDS stats I don't think IOPs will help, because I > don't see any flat lines on my write operations / second graph. Is this > a good assumption? > Not sure what you mean by this. Also, maybe you should talk to AWS if you're on RDS. > • What else can we tune to spread out checkpoints? > Based on the logs, your checkpoints are triggered by filling WAL. I see your checkpoints happen every 30 - 40 seconds, and you only have 64 segments. So to get checkpoints checkpoints triggered by timeout (which I assume is 5 minutes, because you have not mentioned checkpoint_timeout), you need to increase checkpoint_segments enough to hold 5 minutes worth of WAL. That means 300/30 * 64, i.e. roughly 640 segments (it's likely an overestimate, due to full page writes, but well). regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance