Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eRPz5-0008M1-JX for pgsql-performance@arkaria.postgresql.org; Tue, 19 Dec 2017 22:03:35 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eRPz4-0002Oa-LP for pgsql-performance@arkaria.postgresql.org; Tue, 19 Dec 2017 22:03:34 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eRPz4-0002OR-45 for pgsql-performance@lists.postgresql.org; Tue, 19 Dec 2017 22:03:34 +0000 Received: from mail-wr0-x233.google.com ([2a00:1450:400c:c0c::233]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1eRPyw-0006h4-5L for pgsql-performance@lists.postgresql.org; Tue, 19 Dec 2017 22:03:32 +0000 Received: by mail-wr0-x233.google.com with SMTP id f8so9843560wre.4 for ; Tue, 19 Dec 2017 14:03:25 -0800 (PST) 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=BGf9knht6Y4/+1xIsxuom8SLYC50nhc4fqVlcwrnIkc=; b=O4UEo40k5L2ucvPnQp5PFBUrVbMC6fUPUiUJKreua0k9DoY2stb1pHc/v+dkKiwMfp Bd9wyeVkVruyDb/rFKjl48wmqDfLBdu/+yuVBQOcCIR5piPTglv6C1DjSuconJAU14op FEHg7rIOo4ofTXXGVJJkBsKARMid/Ww1Ey3nD4+/6JDNiNBX89hEAEylSpMm82GXFFrO CXLl2A5ORa5IjC17BvVZi9gJ7i2piSqAlqQViYt+jZQEH2Z3LXyBmr8yYbM8XPvXRLwO BQAVaa/ctrET02XNsG1+9Hv+j4pUXgBRSxg3Gh7r/NAWIgY+KJatK3+f+MjC50gBe8ym CB0Q== 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=BGf9knht6Y4/+1xIsxuom8SLYC50nhc4fqVlcwrnIkc=; b=bySCcQFinmN7eKEeq0o6yeO9EnWqCqgxnPec13RmKw8tzU7v3yNNgRVLviOErrhLMa Ph8CKV5Fx8KJnHtGCsgwVO+UCslgUFCtMHGjF+4Zgx25+DDLniqoD5khmCtiwcB33lY+ iztrWeOe4LRgo/gQscTn3R9QpAnZD0nbp7zJEhnRa2Ady2kkxLsW+VEukWREW/5SZUhT /x7VClpHXb9MH4k8tETCfBUwEQbASO8CIVF0D241DRiVg2wdY3w2+GP/z7raW1WADS7z 6t2qCWovJcA0Eo7bvdV0/9B3KPJ8htRDk1stbcgvn5/7P6SuOSDronANAIt6TawFSAod /TVg== X-Gm-Message-State: AKGB3mLzm0kZrXKnVYmrAJ+V3VUbJrJaVN3ukej44H2ng6a2hcAhVyxx jfBJ+aTW84lw0keBEd1PD4h6To4sA0DeQ4Gko059Ekuxc6waPqyW3t+RZv+FGiBNeISjRpljgpy gldsjNLk41NkrHb6lce8uVrm6Xb+tOCivnys74ygXSQ3ArrDY4oLYQ7ZE0Fe7F/EEogrO93/5P4 NC06hWPdXrTiG7MUv56dG5vQ== X-Google-Smtp-Source: ACJfBot3clBuo33qhci1GwPMdRcgBCM0XcDvooBVB3D62CLFEto/CjQHL2xfZm8+WA9846KkUgOlYg== X-Received: by 10.223.179.209 with SMTP id x17mr6524011wrd.145.1513721002899; Tue, 19 Dec 2017 14:03:22 -0800 (PST) Received: from [10.137.2.19] (ip-78-102-97-226.net.upcbroadband.cz. [78.102.97.226]) by smtp.gmail.com with ESMTPSA id d7sm20705381wrd.54.2017.12.19.14.03.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Dec 2017 14:03:21 -0800 (PST) Subject: Re: Autoanalyze CPU usage To: Habib Nahas , pgsql-performance@lists.postgresql.org References: From: Tomas Vondra Message-ID: Date: Tue, 19 Dec 2017 23:03:18 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 12/19/2017 05:47 PM, Habib Nahas wrote: > Hi, > > We operate an RDS postgres 9.5 instance and have periodic CPU spikes to > 100%. These spikes appear to be due to autoanalyze kicking on our larger > tables. > > Our largest table has 75 million rows and the autoanalyze scale factor > is set to 0.05.  > > The documentation I've read suggests that the analyze always operates on > the entire table and is not incremental. Given that supposition are > there ways to control cost(especially CPU) of the autoanalyze operation? > Would a more aggressive autoanalyze scale factor (0.01) help. With the > current scale factor we see an autoanalyze once a week, query > performance has been acceptable so far, which could imply that scale > factor could be increased if necessary.  > No, reducing the scale factor to 0.01 will not help at all, it will actually make the issue worse. The only thing autoanalyze does is running ANALYZE, which *always* collects a fixed-size sample. Making it more frequent will not reduce the amount of work done on each run. So the first question is if you are not using the default (0.1), i.e. have you reduced it to 0.05. The other question is why it's so CPU-intensive. Are you using the default statistics_target value (100), or have you increased that too? regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services