Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fgTNL-00088k-7H for pgsql-admin@arkaria.postgresql.org; Fri, 20 Jul 2018 11:15:08 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fgTNG-0000og-0D for pgsql-admin@arkaria.postgresql.org; Fri, 20 Jul 2018 11:15:02 +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.89) (envelope-from ) id 1fgTNF-0000oN-Cr for pgsql-admin@lists.postgresql.org; Fri, 20 Jul 2018 11:15:01 +0000 Received: from smtp202-pc.aruba.it ([62.149.157.202] helo=smtpg-pc.aruba.it) by makus.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fgTN9-0007ti-MQ for pgsql-admin@lists.postgresql.org; Fri, 20 Jul 2018 11:15:00 +0000 Received: from DT02 ([93.63.211.242]) by smtpcm2-pc.aruba.it with bizsmtp id CzEs1y0065ELnP901zEskK; Fri, 20 Jul 2018 13:14:52 +0200 From: "Alfonso Moscato" To: Subject: repeated out of shared memory error - not related to max_locks_per_transaction Date: Fri, 20 Jul 2018 13:14:53 +0200 Message-ID: <00a601d4201a$e2291a10$a67b4e30$@merqurio.it> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdQgFJyZ3TOVHndJTji2ACGqEB1p5g== Content-Language: it DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aruba.it; s=a1; t=1532085292; bh=AOelfkuRUM1knv53ppSIsJISPOZeSloxSwcdtmnOC0U=; h=From:To:Subject:Date:MIME-Version:Content-Type; b=HR2oGQlIeplwc/xXrPC+YjpGdxfCJ0YOoD6X3VbpxbhlIGF9bPvDF0HVGln1wav+8 cbAdztoiiAQm8nk/OQ7irycoCtlVOadCrrIR4rRu1Dfh/RdGGHVZJpjKY8zi0u93Ws f08GCRKwGCY5nSz/fInrz0l26TEZG0L+HvUvzYawCKpGKkjcyEWYVoG0RbRNs/EpwY npuP+S1IJnLiPr3PrBcpCg30eImy9LatLoi4YC0lo5qPT2Tv0DsoOE+dLDQowjDy4c HT3qZ6vr2jVzXIav68DpgopMZkU5MLwhZRT1mfeSeep7Tj2yQftg4IoUDQ51sfCCAd c7eX4zGbHcBdA== List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk We are getting crazy with "out of shared memory" errors, and we can't figure the reason. We have postgresql "PostgreSQL 9.6.9 on x86_64-pc-linux-gnu (Ubuntu 9.6.9-2.pgdg16.04+1), compiled by gcc (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609, 64-bit", the server has 92gb of ram, it is a mixed environment (mostly OLTP, with some DW), with 100 sessions constantly open (a CRM) and some long queries run every half an hour. Everything works fine, except that after 1 day and half we start receiving a lot of "out of shared memory" messages. I am sure it is not related with the usual max_locks_per_transaction issue, because we have set max_locks_per_transaction to 384, and when we receive these messages we have no more than 50/100 locks totally. Restarting the server usually works fine for one day and hal more, and then messages restart. Looking at the log, we see that this error starts casually, sometimes on very small queries, returning some kbytes of data. We have tried a lot of different configurations. we have tried with pgtune and pgconfig 2.0. Currently, we have: max_connections = 200 shared_buffers = 23GB effective_cache_size = 69GB maintenance_work_mem = 2GB checkpoint_completion_target = 0.9 wal_buffers = 16MB default_statistics_target = 100 random_page_cost = 4 effective_io_concurrency = 2 work_mem = 60293kB min_wal_size = 2GB max_wal_size = 4GB max_worker_processes = 4 max_parallel_workers_per_gather = 2 max_locks_per_transaction = 384 but we tried with work_mem to 130mb, shared_buffer to a maximum fo 40gb, effective_cache to 4gb shared memory limits are very big: max number of segments = 4096 max seg size (kbytes) = 18014398509465599 max total shared memory (kbytes) = 18014398442373116 min seg size (bytes) = 1 thanks