Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1j479H-0003hM-Et for pgsql-hackers@arkaria.postgresql.org; Tue, 18 Feb 2020 17:59:07 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1j479F-0006YM-CA for pgsql-hackers@arkaria.postgresql.org; Tue, 18 Feb 2020 17:59:05 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1j479E-0006WB-RC for pgsql-hackers@lists.postgresql.org; Tue, 18 Feb 2020 17:59:05 +0000 Received: from mail-wm1-x343.google.com ([2a00:1450:4864:20::343]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1j479B-0002X5-IT for pgsql-hackers@lists.postgresql.org; Tue, 18 Feb 2020 17:59:03 +0000 Received: by mail-wm1-x343.google.com with SMTP id t14so3918331wmi.5 for ; Tue, 18 Feb 2020 09:59:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=gmM97SxDb4rQQssFgVowxl0qO7mxySEbNFa668tm1Go=; b=nKlmvwj8Olye4HXfo12IuirNmUuoViPDPzS5Xzqj8xeRavS2WLidE80pfN6presQUw NCvK97aHjADItGsFm+KQ2MYafXWUmDHUW6EonoF/6otgYLtih2z0/KdJ/cCNXx74G/uH +RYbH3vjL3qZPvGaXmPcuvqTFxdt6EsKm6Y+EsDAzka7JxqM5DZ7GY7cQdE0pKZnK6VO VlRsGnZhCtMi8df1AWJtxZomTH8hDywlL8rj784G1mYsHgbdznubQG8ulzZkdM31PWwP o2MSNZL6cnMbTngW1pQT0Tf6q42VeFadBccnBsDCPuze46ZHepY8c3gr0ielyvGyXy4E Kr6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=gmM97SxDb4rQQssFgVowxl0qO7mxySEbNFa668tm1Go=; b=sG57TIqXQgI8ANjE7peiNcQ4kgZAkfsB5wWHKl9ResQqNivQ0/suSrKQgYgRFM/OTw Soi4hmGeOKv6RHz34tz2s69LaJyIVU9PrWUpq7HkEiOVQMVJ8B7WJ/pvQACGSQEslLAC efYaLK6Ze7XyV4hn5sELELwjK71yCQoNPMn0y8ktqw0l34sDGDXgjCwtb6/6kJl+as+k pPs0T/eF5Wog5oHxNXdbxhj2UW6w8hYYuvPr1+2GABu2BTr4sqaCTECFc5T9/isI2v1z FivDh3NN27pyc0kgzYZwoCu5n2RGL0ib73BED9ETRYDKa9OJWrJxl8QV/jHrVU2NKyff KPDQ== X-Gm-Message-State: APjAAAVNVFLxtq8bV7r+v22Cgq2/yTXY3N1bl8WOdgC1wTew57VGn1Tc 9b/j62M1DlhOysoT7O4yT2b0gQ== X-Google-Smtp-Source: APXvYqy5J9WLotkfEH6ewRWhyC/aNPRBOTBtJhlyOHQXNTrerGxLO3xyfR3/crapYBMUEVk9m9qbyA== X-Received: by 2002:a05:600c:22d3:: with SMTP id 19mr4355819wmg.20.1582048739884; Tue, 18 Feb 2020 09:58:59 -0800 (PST) Received: from localhost (ip-86-49-253-92.net.upcbroadband.cz. [86.49.253.92]) by smtp.gmail.com with ESMTPSA id o77sm4488697wme.34.2020.02.18.09.58.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Feb 2020 09:58:58 -0800 (PST) Date: Tue, 18 Feb 2020 18:58:57 +0100 From: Tomas Vondra To: Nagaraj Raj Cc: Pgsql-general , PgAdmin Support , PostgreSQL Hackers , "pgsql-hackers-owner@postgresql.org" , Postgres Performance List , Pg Bugs , Pgsql-admin , Pgadmin-hackers , PostgreSQL Hackers , Pgsql-pkg-yum Subject: Re: DB running out of memory issues after upgrade Message-ID: <20200218175857.5rsxovq5zxmr4wxi@development> References: <1425420656.4660607.1582047988379.ref@mail.yahoo.com> <1425420656.4660607.1582047988379@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1425420656.4660607.1582047988379@mail.yahoo.com> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Tue, Feb 18, 2020 at 05:46:28PM +0000, Nagaraj Raj wrote: >after upgrade Postgres to v9.6.11 from v9.6.9 DB running out of memory issues no world load has changed before and after upgrade.  > >spec: RAM 16gb,4vCore >Any bug reported like this or suggestions on how to fix this issue? I appreciate the response..!!  > This bug report (in fact, we don't know if it's a bug, but OK) is woefully incomplete :-( The server log is mostly useless, unfortunately - it just says a bunch of processes were killed (by OOM killer, most likely) so the server has to restart. It tells us nothing about why the backends consumed so much memory etc. What would help us is knowing how much memory was the backend (killed by OOM) consuming, which should be in dmesg. And then MemoryContextStats output - you need to connect to a backend consuming a lot of memory using gdb (before it gets killed) and do (gdb) p MemoryContextStats(TopMemoryContext) (gdb) q and show us the output printed into server log. If it's a backend running a query, it'd help knowing the execution plan. It would also help knowing the non-default configuration, i.e. stuff tweaked in postgresql.conf. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services