Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1ab8kq-0005na-PT for pgsql-admin@arkaria.postgresql.org; Wed, 02 Mar 2016 15:32:00 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1ab8kq-00041T-Bg for pgsql-admin@arkaria.postgresql.org; Wed, 02 Mar 2016 15:32:00 +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) (envelope-from ) id 1ab8kp-00041I-VM; Wed, 02 Mar 2016 15:32:00 +0000 Received: from mail-yw0-x22e.google.com ([2607:f8b0:4002:c05::22e]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84) (envelope-from ) id 1ab8km-0000j4-Bh; Wed, 02 Mar 2016 15:31:59 +0000 Received: by mail-yw0-x22e.google.com with SMTP id e63so179116140ywc.3; Wed, 02 Mar 2016 07:31:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PK7yrq71ReenBLytLZkaCyaluL0azFsVt8Mo51WIFlI=; b=Tea/bJ64oTuqwOdujFTR3Tnw6LN/0+8BGqvTflsGdLpdiYHOykz9z14bFEWHB59IvK kJ3VRb8MIu1AvQ9mIMDcr0doz0SeBL4Wq0iGeY912Q7iEH9erIECEPnmoz4RMFeGGoGT JXNQwZvxVtuku/zOQFzPHMG8tEOQ3PCG2FksN2VHPDuGuvOhZFywjtwhq0M081TMz5DD 3rgOmK9zUlEfTVtVPhIH10+P9f9Lo80+oW1MUQ1QItMlLiOYJvjkxNvc2GCiBDhmpuIw YqA0gSrtDDubO/wK5iwbOeG91ONiDeIrhC4RISDEuPT7z3Z1VTtYcyLaWfPCRxIrIOgi PdkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PK7yrq71ReenBLytLZkaCyaluL0azFsVt8Mo51WIFlI=; b=NaGfzXfwtimyP08WiwFEhgG6xLdnJxDB4dHJCgzMoqFyaBzgVfs8dgJQGFh62eW3X8 SlraOpWugXkIT3lcTInKh8urQAqQLG74MW6usepMs7a8ozJP5LELjRG4iRwJIvBgwfIS EWcKL6jYg+jbPFrmpjYU6C9bBQUOouXPEMUQAdwK9uxFrgvIvyxL05g2cRvLeLOPIcpJ bhqAGQNnsZ2euKdT/nW20MfCR9aJ65ywrL350/LGlmYitIEXDrndouKEDfcmuJLf/LI5 +FJzlQQxwzatqJEYZbAyL363S+0BJfCnzp3RDvvmDgQShuiG338WF76QQRIWsHtf9T+7 vijQ== X-Gm-Message-State: AD7BkJJnnaXEqE1s5mM24mJafCGzKcYwLoOA+JTUdZEXJpUabY2KfG5e3iXoS3MSTwgoQXTgdlOMhq9TDa7nvw== X-Received: by 10.13.244.4 with SMTP id d4mr17107212ywf.343.1456932714854; Wed, 02 Mar 2016 07:31:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.212.68 with HTTP; Wed, 2 Mar 2016 07:31:15 -0800 (PST) In-Reply-To: References: From: Pavel Stehule Date: Wed, 2 Mar 2016 16:31:15 +0100 Message-ID: Subject: Re: [PERFORM] autovacuum disk IO To: Artem Tomyuk Cc: pgsql-admin , "pgsql-performance@postgresql.org" Content-Type: multipart/alternative; boundary=94eb2c034e8cee3d46052d129429 X-Pg-Spam-Score: -2.7 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-admin Precedence: bulk Sender: pgsql-admin-owner@postgresql.org --94eb2c034e8cee3d46052d129429 Content-Type: text/plain; charset=UTF-8 Hi 2016-03-02 16:25 GMT+01:00 Artem Tomyuk : > Hi. > > I've noticed that autovac. process worked more than 10 minutes, during > this zabbix logged more than 90% IO disk utilization on db volume.... > > ===========>29237 2016-03-02 15:17:23 EET 00000 [24-1]LOG: automatic vacuum of table "lb_upr.public._reference32": index scans: 1 > pages: 0 removed, 263307 remain > tuples: 298 removed, 1944753 remain, 0 are dead but not yet removable > buffer usage: 67814 hits, 265465 misses, 15647 dirtied > avg read rate: 3.183 MB/s, avg write rate: 0.188 MB/s > *system usage: CPU 5.34s/6.27u sec elapsed 651.57 sec* > > Is it possible to log autovac. io impact during it execution? > Is there any way to limit or "nice" autovac. process? > > Thanks to all for any help. > > maybe offtopic - there is known problem of Zabbix. Any limits for vacuum are usually way to hell. But more times the partitioning helps to Zabbix https://www.zabbix.org/wiki/Higher_performant_partitioning_in_PostgreSQL Regards Pavel --94eb2c034e8cee3d46052d129429 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi

2016-03-02 16:25 GMT+01:00 Artem Tomyuk <admin@leboutique.co= m>:
Hi.=C2=A0

I've noticed that autovac. pr= ocess worked more than 10 minutes, during this zabbix logged more than 90% = IO disk utilization on db volume....

=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D>29237   2016-03-02 15:17:23 EET 00000 [24-1]LOG:  =
automatic vacuum of table "lb_upr.public._reference32": index sca=
ns: 1
	pages: 0 removed, 263307 remain
	tuples: 298 removed, 1944753 remain, 0 are dead but not yet removable
	buffer usage: 67814 hits, 265465 misses, 15647 dirtied
	avg read rate: 3.183 MB/s, avg write rate: 0.188 MB/s
	system usage: CPU 5.34s/6.27u sec elapsed 651.57 sec
Is it pos= sible to log autovac. io impact during it execution?
Is there any= way to limit or "nice" autovac. process?

Thanks to all for any help.=C2=A0


maybe offtopic - th= ere is known problem of Zabbix. Any limits for vacuum are usually way to he= ll.

Regards

Pavel
--94eb2c034e8cee3d46052d129429--