Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1XjDns-0002TK-3D for pgsql-performance@arkaria.postgresql.org; Tue, 28 Oct 2014 20:55:44 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1XjDnr-0002RO-Jt for pgsql-performance@arkaria.postgresql.org; Tue, 28 Oct 2014 20:55:43 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1XjDnq-0002RI-Nh for pgsql-performance@postgresql.org; Tue, 28 Oct 2014 20:55:42 +0000 Received: from sam.nabble.com ([216.139.236.26]) by makus.postgresql.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1XjDnn-0004qf-Jb for pgsql-performance@postgresql.org; Tue, 28 Oct 2014 20:55:41 +0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1XjDnn-0006iD-1Q for pgsql-performance@postgresql.org; Tue, 28 Oct 2014 13:55:39 -0700 Date: Tue, 28 Oct 2014 13:55:39 -0700 (PDT) From: jmcdonagh To: pgsql-performance@postgresql.org Message-ID: <1414529739004-5824701.post@n5.nabble.com> Subject: Incredibly slow restore times after 9.0>9.2 upgrade MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: 0.8 (/) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org Hi, we have a nightly job that restores current production data to the development databases in a 'warm spare' database so that if the developers need fresh data, it's ready during the day. When we moved from 9.0 to 9.2 suddenly the restores began to take from a few hours to more like 15 hours or so. We're in Amazon EC2, I've tried new EBS volumes, warmed them up, threw IOPS at them, pretty much all the standard stuff to get more disk performance. Here's the thing, the disk isn't saturated. The behavior I'm seeing seems very odd to me; I'm seeing the source disk which holds the dump saturated by reads, which is great, but then I just see nothing being written to the postgres volume. Just nothing happening, then a small burst. There is no write queue backup on the destination disk either. if I look at pg_stat_activity I'll see something like: COPY salesforce_reconciliation (salesforce_id, email, advisor_salesforce_id, processed) FROM stdin and even for small tables, that seems to take a very long time even though the destination disk is almost at 0 utilization. The dumps are created with pg_dump -Fc and restored with pg_restore -d db -j 2 -O -U postgres PostgreSQL-db.sql. Is it possible that some default settings were changed from 9.0 to 9.2 that would cause this kind of behavior? I'm stumped here. Thanks in advance for any consideration here. -- View this message in context: http://postgresql.1045698.n5.nabble.com/Incredibly-slow-restore-times-after-9-0-9-2-upgrade-tp5824701.html Sent from the PostgreSQL - performance mailing list archive at Nabble.com. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance