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 1mmr2T-0003Ah-AO for pgsql-performance@arkaria.postgresql.org; Tue, 16 Nov 2021 05:29:49 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mmr2R-00074s-SI for pgsql-performance@arkaria.postgresql.org; Tue, 16 Nov 2021 05:29:47 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mmr2R-00074i-FE for pgsql-performance@lists.postgresql.org; Tue, 16 Nov 2021 05:29:47 +0000 Received: from mail-il1-x12e.google.com ([2607:f8b0:4864:20::12e]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mmr2K-0004NJ-ER for pgsql-performance@lists.postgresql.org; Tue, 16 Nov 2021 05:29:46 +0000 Received: by mail-il1-x12e.google.com with SMTP id l8so19127908ilv.3 for ; Mon, 15 Nov 2021 21:29:40 -0800 (PST) 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:content-transfer-encoding:in-reply-to :user-agent; bh=sJqstwwKrXq9NvYrschoccPE0sdwjLnArE7FmV3eUHg=; b=b9E36Cvf36HYFS7RWeQNpUe/wY36XbP5/tZshOhE+VJVlw5flOIsCC0Ae9QMCV3csZ YxwV7s4uEBRkpLMiqCDBW2nJjRrIXcRm+qiPSyf72KpHnA9az7gltg0w7G92dr2wqXJY cTsOkA7pigy3pcStqbFa7XSzbj9ZEU8UBXxzCAW5ZuQaWatRgiyY9DQmruWXwE0LrY6q wjhuzzgdI14hSdkpqO8JziY817Wm/BCKn9eAzLJine97CQgRYnzkUy+xCOvcKDQ6zkd+ rBE+CFOI/vLexi7lq/23/TN56w91ia0H2NsU4eM5b3KGUULaKsJTgPrfbmJgvHv2q4kY eGRQ== 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:content-transfer-encoding :in-reply-to:user-agent; bh=sJqstwwKrXq9NvYrschoccPE0sdwjLnArE7FmV3eUHg=; b=1eoCLw0IX/9YNK9UBsfyo5YrGHRSgBaRR/636HYDw4sjlo0lHHnFNL9Fpt0kChH11R w268rgMjyxI1q5ncSDXWBxJy9hEwZ/bVAuE2kEM+Y3xzZCoV68Tgr4mXpSHyFOyB0Sy+ J3VpKQmH9OGQIQek5gVLNC4lHkqTDDjYmLy9sUHsK4F8CI+u8Yo7Kv2ZZ7e4jQB3ALxL +yVYDqEqROkGejTQ6yxmVJkHRnczdOlrYarB7PA3q3D63Zn9xmMvPewQCDxlwVu7gbwu JamcyrlX9N4vpxYcE3Y7DeOA3ljnXlqr0SlBNlku4QL7IWCIxpoAmoKEk0aVVeCQpGGX L6rw== X-Gm-Message-State: AOAM53390ecLX7zagd4CYA1y/+oQml+Vt2RxaogFDlhd0YApzNH89yh5 ISCA+j+wOK9RHVgJfP5z/wBkyOugLeDh0w== X-Google-Smtp-Source: ABdhPJyP2MOKM8zw1P+Stjel8buKETi31uCmeGVsIBYX+LIISnSjL9oCH5FoVqO0td+6tqVjE61+NA== X-Received: by 2002:a92:cf4b:: with SMTP id c11mr2216330ilr.88.1637040579460; Mon, 15 Nov 2021 21:29:39 -0800 (PST) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id s12sm8905300iol.30.2021.11.15.21.29.38 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Nov 2021 21:29:39 -0800 (PST) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id 3176D800AE5; Mon, 15 Nov 2021 23:29:38 -0600 (CST) Date: Mon, 15 Nov 2021 23:29:38 -0600 From: Justin Pryzby To: Robert Creager Cc: pgsql-performance@lists.postgresql.org Subject: Re: Need help identifying a periodic performance issue. Message-ID: <20211116052937.GW17618@telsasoft.com> References: <3A76761B-3DDD-4A3C-B791-E73107AFC9A2@spectralogic.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3A76761B-3DDD-4A3C-B791-E73107AFC9A2@spectralogic.com> 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 Tue, Nov 16, 2021 at 04:43:25AM +0000, Robert Creager wrote: > We’re executing the following copy to fill a table with approximately 5k records, then repeating for a total of 250k records. Normally, this copy executes < 1 second, with the entire set taking a couple of minutes. The problem is not reproducible on command, but usually within a couple of hours of starting some test runs. > > COPY ds3.blob (byte_offset, checksum, checksum_type, id, length, object_id) FROM STDIN WITH DELIMITER AS ‘|’ > > But, occasionally we get into a huge performance bottleneck for about 2 hours, where these copy operations are taking 140 seconds or so > > Nov 15 22:25:49 sm4u-34 postgres[5799]: [381-1] db=tapesystem,user=Administrator,app=PostgreSQL JDBC Driver,client=127.0.0.1 LOG: duration: 145326.293 ms statement: COPY ds3.blob (byte_offset, checksum, checksum_type, id, length, object_id) FROM STDIN WITH DELIMITER AS '|' > I’m logging statements with pgbadger monitoring the logs. There are no apparent auto-vacuum’s running, nor any vacuums, nor anything at all really. Other select queries around that time frame are executing normally. What about checkpoints ? Would you show the "^checkpoint starting" and "^checkpoint complete" logs surrounding a slow COPY ? > We’re coming from PostgreSQL 9.6 on FreeBSD 11 where we did not see this problem, but have a major release upgrade happening. I’m checking to see if this machine was updated or was a fresh install. > PostgreSQL 13.2 on amd64-portbld-freebsd13.0, compiled by FreeBSD clang version 11.0.1 (git@github.com:llvm/llvm-project.git llvmorg-11.0.1-0-g43ff75f2c3fe), 64-bit > > Changes made to the settings in the postgresql.conf file > checkpoint_timeout | 30min | configuration file > log_checkpoints | on | configuration file > log_lock_waits | on | configuration file ... > shared_buffers | 21679MB | configuration file > Operating system and version: > FreeBSD sm4u-34 13.0-STABLE FreeBSD 13.0-STABLE #0: Mon Sep 13 10:11:57 MDT 2021 > These are the system calls made over 30 seconds from Postgres during a slowdown. ... > fsync 27 -- Justin