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 1nX2mk-0002MG-37 for pgsql-performance@arkaria.postgresql.org; Wed, 23 Mar 2022 15:20:30 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nX2mi-0007Xh-V3 for pgsql-performance@arkaria.postgresql.org; Wed, 23 Mar 2022 15:20:28 +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 1nX2mi-0007XY-I0 for pgsql-performance@lists.postgresql.org; Wed, 23 Mar 2022 15:20:28 +0000 Received: from mail-il1-x129.google.com ([2607:f8b0:4864:20::129]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nX2mf-0005hQ-Hf for pgsql-performance@postgresql.org; Wed, 23 Mar 2022 15:20:28 +0000 Received: by mail-il1-x129.google.com with SMTP id y7so1223121ilv.6 for ; Wed, 23 Mar 2022 08:20:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=zGGiMWNXyNt44xO0v8MpjyC9XnKvCYuo7/OmJkSvtoA=; b=QbIfq5ms4Reln9UTlb2BmloNbeoF1lTKHeSqvCpAgY6C694F6kL2HW/bwNBn9w9NUn EkWGe9bBrc/617rcKzIbbUgYVUtsKBrAY+0uo+YtIUFxIFZZa1I7NgCopzOLjljoVlgX QPfneKkHv/4gEcmZUyohuJ13w2lk0Bkk1N/txLTjNOx+6HNCkTgFYzHqywsrCwVNbHIt UoUYO0I+/R/+/BKR79PCiTPGRw0nDf6H1WPFcvTvs/6HAyjvDA0coV+VzjI6i+yciHL2 4/Tai4XheMsyEyOWVRV7u1aNGo4HHDBrWxUBCOQntuumTEm++e6P+NlZsooAvwAAgjIH 148w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=zGGiMWNXyNt44xO0v8MpjyC9XnKvCYuo7/OmJkSvtoA=; b=YxOuZI5HQ1y5MGXhxQ9rSL2C+RnoYmdUECx2ghMcCt60YPzngD3UNr2UofvJZZMAuh F1Jzau8CfOIfF9C6Ieq+CCi/Fhp2PiH9pbQJHOnxVMABuF1Nj7iSqAgICXtZRVtx8FId 4pdhQ6QdQ7rXh8NDIrnvqUNbyDX/lAmv9dD67dh5rT6tcey9VITrqkjRFvIpFxzDLUhm MptTFBSOqKZxcLcn2YnMYWrXuMDFDs0lGOvi1jRGdhPC8+B8Wr9OZVzTJeX2BCLDB3zQ 34nUtD0l6HVeKg6+49NVeEEnXarD6Iy/Ewc9OU5uqR5Aft7QSxXhVXGNAZT2i8A37hmO 1oWw== X-Gm-Message-State: AOAM532sckrFdxTJ7qb66GvYpDXEyv4rn2xRufuLZoPOop9VHlQFrohK H+ETAuT9hM6M9q9sgCDFCdm8Cw== X-Google-Smtp-Source: ABdhPJyJG3SX9yfJbQ1siCKqf/GbZHiqGFA05lZNTLgEK9e+bOODvWR0OlyO0Yxa51wbBPgq2BjQCA== X-Received: by 2002:a05:6e02:1746:b0:2c7:f247:b378 with SMTP id y6-20020a056e02174600b002c7f247b378mr288596ill.298.1648048823760; Wed, 23 Mar 2022 08:20:23 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id g2-20020a056e021e0200b002c82a3f69cesm226819ila.8.2022.03.23.08.20.23 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Mar 2022 08:20:23 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id 8B25D804867; Wed, 23 Mar 2022 10:20:22 -0500 (CDT) Date: Wed, 23 Mar 2022 10:20:22 -0500 From: Justin Pryzby To: Shai Shapira Cc: pgsql-performance@postgresql.org Subject: Re: High process memory consumption when running sort Message-ID: <20220323152022.GT28503@telsasoft.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Mar 23, 2022 at 02:42:06PM +0000, Shai Shapira wrote: > Hi, > > When running our application, we noticed that some processes are taking a lot of memory ( 10, 15, 20GB or so, of RSS ). > It is also reproduced when running in psql. Note that RSS can include shared_buffers read by that backend. That's a linux behavior, not specific to postgres. It's what Andres was describing here: https://www.postgresql.org/message-id/flat/20201003230149.mtd7fjsjwgii3jv7@alap3.anarazel.de You have effective_cache_size = 48GB, so this seems to be working as intended. (ecc is expected to include data cached not only by postgres but by the OS page cache, too). > Memory consumption: ( of case 2, application table, using system_stats ) I'm not sure, but I guess this is just a postgres view of whatever the OS shows. > Using top: > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 15298 postgres 20 0 16.8g 1.1g 1.1g S 0.0 1.7 0:02.63 postgres > PostgreSQL 12.6 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44), 64-bit > Linux illin7504 3.10.0-1127.19.1.el7.x86_64 #1 SMP Tue Aug 11 19:12:04 EDT 2020 x86_64 x86_64 x86_64 GNU/Linux > shared_buffers | configuration file | postmaster | 2097152 | 8kB | 1024 > effective_cache_size | configuration file | user | 6291456 | 8kB | 524288 > work_mem | configuration file | user | 20480 | kB | 4096