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 1v6uOi-00BisW-S2 for pgsql-general@arkaria.postgresql.org; Thu, 09 Oct 2025 17:25:49 +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 1v6uOf-007aOa-Cz for pgsql-general@arkaria.postgresql.org; Thu, 09 Oct 2025 17:25:46 +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 1v6uOf-007aOQ-0J for pgsql-general@lists.postgresql.org; Thu, 09 Oct 2025 17:25:45 +0000 Received: from npq-east2-cluster1-host7-snip4-3.eps.apple.com ([57.103.77.106] helo=outbound.st.icloud.com) by makus.postgresql.org with smtp (Exim 4.96) (envelope-from ) id 1v6uOc-000tm6-1F for pgsql-general@lists.postgresql.org; Thu, 09 Oct 2025 17:25:44 +0000 Received: from outbound.st.icloud.com (unknown [127.0.0.2]) by p00-icloudmta-asmtp-us-east-1a-100-percent-1 (Postfix) with ESMTPS id 29939180016C for ; Thu, 9 Oct 2025 17:25:39 +0000 (UTC) Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nunnari.ch; s=sig1; bh=NwAMUIe9SXPj30ZKhRn5vT/3hx3lHsr6cqXFyUWokPg=; h=Message-ID:Date:MIME-Version:To:From:Subject:Content-Type:x-icloud-hme; b=Y/AQjx8UyR7cVdi/5wJoTXmI4BdZ0C19e39OTRbRdDWH4+nkCGUus3WL7jFbF9jLpdsnQxmK05pVoJv95F/rlY8MKbKxVxCw7Z0MfR9qRN84biq+bWusQ7SH3wLkGulsiZQHndTMxnSCMUIL2GRABkaKBvQUOQhE3AZpXVWKogeks1nN8KIWjzpPHup/dsKGgFZDua1h1V88JnK/0zjyE/siJwAzVwxRTgv2yOGmSdqrjV/gZNSrBS5zJdW5tLW080T5CiWqlT381VCMbzfP/n1p0RfTbnC04CrAXTCz0SicJnt2X8te7zeP89mnDTedAHHpwX/7NMXClqtnBFe5hw== mail-alias-created-date: 1516299501000 Received: from [192.168.1.26] (unknown [17.42.251.67]) by p00-icloudmta-asmtp-us-east-1a-100-percent-1 (Postfix) with ESMTPSA id 38AF718005B4 for ; Thu, 9 Oct 2025 17:25:38 +0000 (UTC) Message-ID: Date: Thu, 9 Oct 2025 19:25:34 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: it To: pgsql-general@lists.postgresql.org From: Roberto Nunnari Subject: High latency and profiling Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Proofpoint-GUID: i8ULs69bnM-k2cxOeRuz2XsdXJkaqf0V X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUxMDA5MDEwNiBTYWx0ZWRfXxSeOps+JLvwE 6N+coycMoiPCh9Qwy63LramftPpYY6Z+AtBGsE68Wf2sb4KNpDZug2eBnoeI0Cz7LzfG+efV4aO c+C9H7DLdRPVMLtgyY2wkqvO4gQu06rITivYNaE8vFMvQe8L6O6aJFjcFQy95A+pYixDxqAv7hJ dYCLfDiLmUloCiobTakkkes2+2AaWjrBoHci0c6uaVl7GFwdx83fQ4P1Bnn0Yhfoimz05mGc/IX gA21Pi9FuO6Q00SwJtrCoe495CtFlG0TGDdgylNYasxggzTwGZ3AFchfj1yNJEmwCY1ni1AJc= X-Proofpoint-ORIG-GUID: i8ULs69bnM-k2cxOeRuz2XsdXJkaqf0V X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1117,Hydra:6.1.9,FMLib:17.12.80.40 definitions=2025-10-09_06,2025-10-06_01,2025-03-28_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 spamscore=0 bulkscore=0 malwarescore=0 phishscore=0 adultscore=0 clxscore=1030 mlxlogscore=824 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.22.0-2506270000 definitions=main-2510090106 X-JNJ: AAAAAAABK9pjlAqSgCGC8HqPQFwhyhJtavkgPBjw4zNYS7lFeOX5xa4Y0PUGY+rg4DG2VhelLpoErslGfH92pBxuf7+rxreKKSJQ95xcc3XCMWOvlROA4gTc50exvJuAEiXpYwBXFwL1ZdTdByCCSx0LJaOmTkyw/OuJi8/DyRgB6DI+WkRRYKzJ97qEkUVxgXwGuGEKYab4xKVQVrnlu3+yVTNhojUiVmSUintyIxo9iVyjOeQJzncCgcbzr5mKEaDjE2d7KGaNySoe/0Cm8F3UzrezwOdQYK+YmGDiBdhDLWh8qzc+dwn8ttDfj0BfFmNcbIwXeHd41fD2zXH5OwvbM8Xvs4wJuozQLwyOLCJ9596jzOdvW5AzY8S919sfIcevtHL08Iy9HghufSFM701jTSkD0Vlf1EtpOrNqiqd9XGxskwvkJlRMB56yyI0rsJcnitPCDpHXPI1Uo79SDtXE1vs/0nG4sHWbUJwSm9y2mZNWB+K71nu3I6SOt/Bk/gNUj+zm+fHMzASIpw05iXV/lopr2DPOVkuRiB5wr/O5x+n+thdjkqaF+SEGndGXYKVEw1LMcJ/z6Ov20Ik3iRMMYae2 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hello. Hope this email will keep the formatting this time.. I was notified about high latency on one of our PostgreSQL clusters. This latency is observed from the application and has been increasing. There is no indication about the exact database as the application uses several DBs, but the largest and most used is 'mydb'. So, a couple of months ago I installed pg_profile and configured it as follows: shared_preload_libraries = 'pg_stat_statements,dblink,pg_stat_kcache,pg_wait_sampling' pg_profile.max_sample_age = 90 \c postgres CREATE SCHEMA extensions; CREATE EXTENSION dblink SCHEMA extensions; CREATE EXTENSION pg_profile SCHEMA extensions; \c mydb CREATE SCHEMA extensions; CREATE EXTENSION dblink SCHEMA extensions; CREATE EXTENSION pg_stat_statements SCHEMA extensions; CREATE EXTENSION pg_stat_kcache schema extensions; CREATE EXTENSION pg_wait_sampling schema extensions; CREATE EXTENSION pg_profile SCHEMA extensions; select extensions.set_server_size_sampling('local','23:00+01',interval '2 hour',interval '8 hour'); CREATE USER collector_user with password ''; GRANT pg_read_all_stats TO collector_user; grant connect on database mydb to collector_user; ALTER ROLE collector_user SET search_path = extensions,public; The postgres user had the following crontab: 13,43 * * * * psql -d mydb -c 'SELECT extensions.take_sample()' > /dev/null 2>&1 I made sure autovacuum works correctly and after that, just to make sure, I run vacuum analyze on all DBs. This has not lead to any notable improvement in the latency as seen by the application. I access pg_profile data from grafana, but I cannot see anything that looks wrong. Overall Hit Ratio is always between 99.3% and 100%. The only strange thing I see in grafana, are the following: Overall statement times sais "No data" and 'db query error: pq: column "blk_read_time" does not exist'. Also the graph "Statement time" says "No data" and "db query error: pq: column sst.blk_read_time does not exist". Wait event types (statements) graph: N/A was quite stable at about 0.200 s/s until 2nd september and then grow regularly and sharply up 4 s/s until 22nd september when it dropped back to 0.7 s/s and is stable at that value till now. Developers report that their software is already optimized and database size is not a problem. They suggest the issue might be inside PostgreSQL itself. Could somebody help me understand what is causing the growing latency? Also, but more related to pg_profile, what does the N/A data in the "Wait event types (statements)" graph represent? Thank you and best regards. Robi