Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1main3-00025j-RZ for pgsql-performance@arkaria.postgresql.org; Wed, 13 Oct 2021 18:15:45 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1main1-0003gy-Rd for pgsql-performance@arkaria.postgresql.org; Wed, 13 Oct 2021 18:15:43 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1main1-0003gq-JP for pgsql-performance@lists.postgresql.org; Wed, 13 Oct 2021 18:15:43 +0000 Received: from mout.perfora.net ([74.208.4.197]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1maimz-0002GN-8q for pgsql-performance@lists.postgresql.org; Wed, 13 Oct 2021 18:15:43 +0000 Received: from [192.168.1.167] ([98.169.214.209]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MBVXk-1mQEwQ3QWM-00AWZV; Wed, 13 Oct 2021 20:15:36 +0200 Subject: Re: Lock contention high To: Justin Pryzby Cc: Ashkil Dighin , pgsql-performance@lists.postgresql.org References: <20211013164805.GC27491@telsasoft.com> From: MichaelDBA Message-ID: <0b264a08-b723-eec2-c667-49f17b0a487c@sqlexec.com> Date: Wed, 13 Oct 2021 14:15:34 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 PostboxApp/7.0.49 MIME-Version: 1.0 In-Reply-To: <20211013164805.GC27491@telsasoft.com> Content-Type: multipart/alternative; boundary="------------3ECF0B904F017461E459401C" Content-Language: en-US X-Provags-ID: V03:K1:6jEZP9LRLwtHnPELt1NSvHE+h5bw4CuQ+BZlOKqtwCLTPJu5cJl Kgq5BeJTzceslXbZdbBCig5YOpmuH+bseXjvFIFZTwQeZ84Vc89ANmxMobz0X8VbBrnbnGJ cI3HRr6FuPCDm+vbsBpuoUmPdjH8t4r10C84Fjy3yVk9m3w1pTq6QMjXGD3a0bLZGt2SEcT +iLDGn/z6o1TVZ2rBqfnQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:AHckjOB++1Q=:AonD/H5LTxAwgbH0pOMcnn vn2ihyIA3jZ0caktNXUugzotJh3Qw3DdSbDAojgODAmTDUKB8CkyVPzK/L0HRM31A6ZRGF0jZ Femj8mW5L0l8TLEfMCVkURdEZyJAfehzwVADvi7usLF8TfL+grFgjmRG0wvrG8kWxfk5nwRbO r2pHpa49HSLQ2Oem9OQ875MzbgrWLnehS18ZWb/3cSEsHHIz4d3nFBOjFYtnPXk/UMSf18dSs rIhVKBd5ljPurY6Q38VR/gb49ojiVHcADBX1wQjKaqp504+oqNF242Ti5HlekSwBwiqDlVZlb k9zYZOniBh9mgGiPfCiIovj5MKQ9a2PkuUWjR9/ycLX98Mm7PY7ykPPOZHhxxXJtO3IA9r7Io fHlGpyzBXhsN4dCcrdbwg0Z0Jblp2uFwbddh0wzjWXsJWYVuNmC1c1+O8p7ozIQtwCM7WL3j3 7iSZpA043Xw+wuNsOOcAZ/Y3Vu9tlD+9gvbBX2aBedFnixkPIdI1C+rA7MDJP3YCKraUVTjgk CVNdPqwoYcm9+Ii7AHK8rU/jT6QBr63a3Ccj+//wDGw74aypm+M+ArGVFKYcgz2VLcJDv4PLU DKblyksWo/YsBVTbs4DR3M2dVgv96z6bUOlVrEgIyfRtNfyWb4CuoGEYR3Ygn9hPmMLqDu6X8 Yq7yrcIDcL3VNbhNORrP8gw9U2FW54sTK0sMaQMtaXlQGlhQJcg+S5o57jnypCfesuWc1SsYK cB1hxBX8xP5BXJldYy+EPW2+6JL5pmu/nyb96g== List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------3ECF0B904F017461E459401C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit > 1.Is there a way to tune the lock contention ? > 2.Is any recommendations to tune/reduce the lock contention via postgres.conf I think you'd want to find *which* LW locks are being waited on, to see if it's something that can be easily tuned. You can check pg_stat_activity, or maybe create a cronjob to record its content for later analysis. Hello, Also turn on log_lock_waits so you can evaluate the actual SQL causing the problems in the PG log files.  Thinking ahead, you may want to consider if using advisory locks from the application side of things might be helpful to manage locks in a more pessimistic way.  Also, join with pg_locks table to find out the specific resources that are in contention. Regards, Michael Vitale --------------3ECF0B904F017461E459401C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
1.Is there a way to tune the lock contention ?
2.Is any recommendations to tune/reduce the lock contention via postgres.conf
I think you'd want to find *which* LW locks are being waited on, to see if it's
something that can be easily tuned.

You can check pg_stat_activity, or maybe create a cronjob to record its content
for later analysis.


Hello,
Also turn on log_lock_waits so you can evaluate the actual SQL causing the problems in the PG log files.  Thinking ahead, you may want to consider if using advisory locks from the application side of things might be helpful to manage locks in a more pessimistic way.  Also, join with pg_locks table to find out the specific resources that are in contention.

Regards,
Michael Vitale


--------------3ECF0B904F017461E459401C--