Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tM8eB-0025NS-IR for pgsql-admin@arkaria.postgresql.org; Fri, 13 Dec 2024 16:36:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tM8e9-008wxp-2K for pgsql-admin@arkaria.postgresql.org; Fri, 13 Dec 2024 16:36:10 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tM8e8-008wxh-IB for pgsql-admin@lists.postgresql.org; Fri, 13 Dec 2024 16:36:09 +0000 Received: from mail-ot1-x331.google.com ([2607:f8b0:4864:20::331]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tM8e7-002eVk-IM for pgsql-admin@lists.postgresql.org; Fri, 13 Dec 2024 16:36:08 +0000 Received: by mail-ot1-x331.google.com with SMTP id 46e09a7af769-71e2764aa46so1089113a34.2 for ; Fri, 13 Dec 2024 08:36:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734107766; x=1734712566; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=dgzpm2kN7c5vHBYjmoX8CwXEL78Gtlgvukrs/lVP+Oo=; b=Ds0cS1u8EnOpZlyD/DnedVaM/okU9iXe8sT3qGQpZecelQZrsWQqDvMBVHk6icE7rd P0BTQ4Jd+loDZjg5bAvwtKgc8viV7+chpYix9Z9CSP57e1Fxiqi3b97WGqho8c1+Hcdb onLIXETmEPaIrTrfHxyoXdtthaBpPhLkgFRlbIMzR+UwEpnZ1aECYnXyY3N53M77J+5d ka6qA679/DH/YrVaKBwoP4fyD4Td9FaJ/8dy6RU9QtLDdsb62LyqsCDTGxec9OhF0aHi Iyl6nXlsg0/A9+muMqAuBOqXMRjxt4hMbVfWrmSlyTfFh9HtiGzhnXlzkb1cSdr2v/dv YPBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734107766; x=1734712566; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=dgzpm2kN7c5vHBYjmoX8CwXEL78Gtlgvukrs/lVP+Oo=; b=h1jrSxDGowhYnW926KuYIexLer3PUAfJBV6wW3FGQRjDNBU1kKkH5F2OYg8iI1MlfJ C7opNg64/Tzsnk5lzbsNdpqKHQGSyfNdQGzRyIN2vPBlfY16q2YtCJLFWLQqrIPPI6Az afSi3jQ4b9wGFTpM7pzFlBb7Ecjl4qsHYA7vAxLw6jzNlAa11G5Oc0sJcd7Dsxz2yvtS mGM/Aoawa5OVcfT47ym4xZvrtIS3oLRd2OE/LIp9siwH8C8r6i9sewnY0pGqvLCXgfY2 rpC84PLFEBxoVBnIpUGdnZkl2Ig+PnRBFY2oPuPDXAvxDs2QcFEMUSLV6SAmiwGgform SK6Q== X-Gm-Message-State: AOJu0YymmRPYHPmK4ocUOtDKQ7NBreVpxceAVxPqMvCXHHtLHAaIQBfw Fql9wNyEqtmWWAfwR8doi/EV4rG5Tk5RkGiVZRXrWkNBK6rs/6wmZ6BADJe5ybzPCSzaGo3RJCM 6xzWhcvAsiYjpTlwzepZhQ9KMg2hwikFl X-Gm-Gg: ASbGncvDKb1NH4cC90m+lGsNsb5ITvE0bjjzqPchrs6V8ZuZQ2EEH7a8wLFWXgNJFPq 6gBQMdcN3FfHcVykJxuf6TTwg8/Vf6N1UJ1LdrcRV/nRKyGanfyNTmIYh6pSS9pDzLzuOWzhh X-Google-Smtp-Source: AGHT+IFBF6yEXKd85JcECapw6XeTnOk090mN/LxQY6g1IVxSfbcw63lp70DlwHjsI8asw8p3jCTcCq90BRVkqciJ3xo= X-Received: by 2002:a05:6871:442:b0:29d:c624:7cc4 with SMTP id 586e51a60fabf-2a3ac537265mr1787760fac.6.1734107766407; Fri, 13 Dec 2024 08:36:06 -0800 (PST) MIME-Version: 1.0 From: Ron Johnson Date: Fri, 13 Dec 2024 11:35:55 -0500 Message-ID: Subject: Benefit to increasing max_files_per_process? To: Pgsql-admin Content-Type: multipart/alternative; boundary="0000000000006b4b1e0629296ddd" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000006b4b1e0629296ddd Content-Type: text/plain; charset="UTF-8" PG 14.13 on RHEL 8.10 max_files_per_process is the default 1000. Currently, many connection processes are hovering around 990 open files. Does PG purposefully close some unused files when getting near the max? Would we see benefits to increasing max_files_per_process as well as running "ulimit -n 2500" (and then of course restarting PG). I don't see any "too many open files" errors in the log file, but am trying to plan ahead. -- Death to , and butter sauce. Don't boil me, I'm still alive. lobster! --0000000000006b4b1e0629296ddd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
PG 14.13 on RHEL 8.10

max_fi= les_per_process is the default 1000.

Currently, ma= ny connection processes are hovering around 990 open files.

<= /div>
Does PG purposefully close some unused files when getting near th= e max?=C2=A0 Would we see benefits to increasing max_files_per_process as w= ell as running "ulimit -n 2500" (and then of course restarting PG= ).

I don't see any "too many open files&q= uot; errors in the log file, but am trying to plan ahead.

--
Death to <Redacted>, and butter sauce.
Don't boil me, I'= m still alive.
<Redacted> lobster!
--0000000000006b4b1e0629296ddd--