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 1tOc2q-007YgM-EA for pgsql-admin@arkaria.postgresql.org; Fri, 20 Dec 2024 12:23:52 +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 1tOc2p-00Ac26-GT for pgsql-admin@arkaria.postgresql.org; Fri, 20 Dec 2024 12:23:51 +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 1tOc2p-00Ac1y-31 for pgsql-admin@lists.postgresql.org; Fri, 20 Dec 2024 12:23:50 +0000 Received: from mail-wm1-x330.google.com ([2a00:1450:4864:20::330]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tOc2m-000Y9Q-63 for pgsql-admin@lists.postgresql.org; Fri, 20 Dec 2024 12:23:49 +0000 Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-436637e8c8dso14081655e9.1 for ; Fri, 20 Dec 2024 04:23:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734697426; x=1735302226; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=UoK+dHtn9orKkQpTj7fzVx4o0buqWT2gPxDAIxm6xyI=; b=bxLOUI2FZ7bcU36muPor+3zkRnSVCTzrWX+Rl2nAX5gs0DDSXtZtM/APvuIxYq9ZVZ b5S4zr+sixI2kuyXcY5gyFvstBBPIp1Jk6CiBFhhzA+sturEXakeTNFH3fBwFW5PdyAm Ybpgu77dwcvufOz/qN6HpEcY6JWxT9fSgYZAR1Xpr+Ya6oUwHBhbG9yAShjjDCh+SlPs fhO5ncQOKX+/HRilDFFs4B4+c/f0fkwvSi56AKdS2oJY2rpq20lAY1KZqLyNpXzmq1qB Kf73dGYgXwsVfRsN+xtDi7WBuY/3IDZUNU4FSMFWotaSMgz0JHm8bZEgaSScn6X+lVB9 psyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734697426; x=1735302226; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=UoK+dHtn9orKkQpTj7fzVx4o0buqWT2gPxDAIxm6xyI=; b=kt7NDUjKV7w7FRNQ9u987DvdH+Td/MTJvAydc47XqHJhrNhIFSnjvNBNcX6aMXrs9J B5cJRQMOc1QRPjDsMlrQZboPFs8mGnbztIZA1NiT2vtrEAvPOmmHlwGYz31w8uxjcUoA /Hnu4jgD41eAgX/hitq4a0ZZOQB+4zMFd7yojE9RILDz8aNPelRwMgI0ckkfzLYQQxSV zUn5OgRtY+VG43lYXv91viE9ohh7WAd9F/kLFDXV31sebU/WzMj4UexUZYu7MkV8CZq3 wYyIgjBWuq8W5Yc+0EIYIC6QOhO26vjfmQOWifPxc5q1Jr6IxaBiwJGM4leQQKYmNYN2 Ta1Q== X-Gm-Message-State: AOJu0YwRjXn/K1JySxa6B2Mc0BDF6kzpnDz8LaYzFUEBgE97OG2erOot 8Ng8c+9OVl0T2kgEeC5NXWvymomuHflUwu8ffqiyzFyag3sFZF/kgfuFyW2HBEanPRtDME3KmoK KYUN8/wP/Ncz0TczQJC+aHZBqkUJsEPO4Aig= X-Gm-Gg: ASbGncvFdDMxZYE3qY+WaryKd+7iEHEv3WJgy1ZwAlzTUwKM1YfTrAaNLxWFJz7ZRQn 2QiPghjt6blnFcvUBXhRQKsbzeYQAEY4zK1LA X-Google-Smtp-Source: AGHT+IEaYIdWLUzHNAhucjCrW8dd7N1O7Fdnfc4xZopGNCFa/ZAyj18B2YCLiBqlCMgQiBWqo+V0qaPyl5Y5nR7SErE= X-Received: by 2002:a05:600c:35c1:b0:434:a94f:f8a9 with SMTP id 5b1f17b1804b1-43668b7873emr19787305e9.28.1734697425803; Fri, 20 Dec 2024 04:23:45 -0800 (PST) MIME-Version: 1.0 From: SOzcn Date: Fri, 20 Dec 2024 15:23:34 +0300 Message-ID: Subject: Troubleshooting - PostgreSQL Session CPU Analyze To: Pgsql-admin Content-Type: multipart/alternative; boundary="000000000000dba8f70629b2b7c5" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000dba8f70629b2b7c5 Content-Type: text/plain; charset="UTF-8" Hello, I have created a simple structure to monitor the pg_stat_activity table on the database. There's no issue with this; I can log it as desired. However, our main need is to see the CPU usage percentage consumed by each session. You can think of it as an analysis similar to the spWhoIsActive method in SQL Server. However, I cannot determine the load caused by a specific query on the server at a given moment. Even if I try to match PIDs on the system, this approach might not yield accurate results due to interventions like session kills during the check. I would appreciate it if you could share your experiences and recommendations on this matter. In standard processes, I can perform real-time analyses using the following query: SELECT pss.userid, pss.dbid, pd.datname AS db_name, round(pss.total_exec_time::numeric, 2) AS total_exec_time, pss.calls, round(pss.mean_exec_time::numeric, 2) AS mean_exec_time, round((100 * pss.total_exec_time / sum(pss.total_exec_time::numeric) OVER ())::numeric, 2) AS cpu_portion_pctg, pss.query, psa.client_addr AS client_host FROM pg_stat_statements pss JOIN pg_database pd ON pd.oid = pss.dbid JOIN pg_stat_activity psa ON psa.query = pss.query ORDER BY pss.total_exec_time DESC LIMIT 30; When I attempt to log this query, it will only provide statistical responses, meaning the differences will not yield 100% accurate results on the actual server. Have a nice day! --000000000000dba8f70629b2b7c5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

I have created a simple structure to monitor= the pg_stat_activity table on the database. There's no issue with this= ; I can log it as desired.

However, our main need is to see the CPU = usage percentage consumed by each session. You can think of it as an analys= is similar to the spWhoIsActive method in SQL Server.

However, I can= not determine the load caused by a specific query on the server at a given = moment.

Even if I try to match PIDs on the system, this approach mig= ht not yield accurate results due to interventions like session kills durin= g the check.

I would appreciate it if you could share your experienc= es and recommendations on this matter.

In standard processes, I can = perform real-time analyses using the following query:

SELECT
=C2= =A0 =C2=A0 pss.userid,
=C2=A0 =C2=A0 pss.dbid,
=C2=A0 =C2=A0 pd.datna= me AS db_name,
=C2=A0 =C2=A0 round(pss.total_exec_time::numeric, 2) AS t= otal_exec_time,
=C2=A0 =C2=A0 pss.calls,
=C2=A0 =C2=A0 round(pss.me= an_exec_time::numeric, 2) AS mean_exec_time,
=C2=A0 =C2=A0 round((100 *= pss.total_exec_time / sum(pss.total_exec_time::numeric) OVER ())::numeric,= 2) AS cpu_portion_pctg,
=C2=A0 =C2=A0 pss.query,
=C2=A0 =C2=A0 psa.c= lient_addr AS client_host
FROM
=C2=A0 =C2=A0 pg_stat_statements pss<= br>JOIN
=C2=A0 =C2=A0 pg_database pd ON pd.oid =3D pss.dbid
JOIN =C2=A0 =C2=A0 pg_stat_activity psa ON psa.query =3D pss.query
ORDER BY=
=C2=A0 =C2=A0 pss.total_exec_time DESC
LIMIT
=C2=A0 =C2=A0 30;=

When I attempt to log this query, it will only provide statistical = responses, meaning the differences will not yield 100% accurate results on = the actual server.

Have a nice day!
--000000000000dba8f70629b2b7c5--