Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 8F13065022A for ; Tue, 26 Aug 2008 15:27:46 -0300 (ADT) Received: from postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 67676-01-2 for ; Tue, 26 Aug 2008 15:27:39 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.235]) by postgresql.org (Postfix) with ESMTP id B04E7650341 for ; Tue, 26 Aug 2008 15:23:32 -0300 (ADT) Received: by qb-out-0506.google.com with SMTP id d8so3611763qbc.23 for ; Tue, 26 Aug 2008 11:23:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=/ic/JNeTNCYQJASzJyU3/IRkMZslEoMs0wVFvaUmlRM=; b=sn+uwZXH5W8OS6elD5/EPauBiXRX+etaJqjLsoEOCj3ym8DhQar1DD0LL1AtaSO0LU XgIyDsL8kSbqJuqVeHePaidINV1B8KXvPYY9j9T9r3bZKEPdv8GEPd0Vx2ZX5XWc84mV 1aqWlMwZ7UXAAI+s4iysqshCVGoOmqj7WqQOA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Eo3ck3kMbfLJIoZikCH1BpFISfvrfNJ7psmjcy+kAp7TEW2n63VS3FCNGqB9cZgbVf rYv61hs0PQy1t/SaZPiXwHKwWsjIbOQAELR6Uudlew/AZXNDNAxyv2XL1r/oJz8YGRqG IKmbsV+QUJskMqpFU24D5Nw7qLOXyZxGvf10Q= Received: by 10.140.188.10 with SMTP id l10mr3051389rvf.6.1219775010955; Tue, 26 Aug 2008 11:23:30 -0700 (PDT) Received: by 10.141.197.1 with HTTP; Tue, 26 Aug 2008 11:23:30 -0700 (PDT) Message-ID: Date: Tue, 26 Aug 2008 12:23:30 -0600 From: "Scott Marlowe" To: "henk de wit" Subject: Re: select on 22 GB table causes "An I/O error occured while sending to the backend." exception Cc: pgsql-performance@postgresql.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200808/338 X-Sequence-Number: 31219 On Tue, Aug 26, 2008 at 10:44 AM, henk de wit wrote: > > Hi, > > We're currently having a problem with queries on a medium sized table. This table is 22GB in size (via select pg_size_pretty(pg_relation_size('table'));). It has 7 indexes, which bring the total size of the table to 35 GB (measured with pg_total_relation_size). > > On this table we're inserting records with a relatively low frequency of +- 6~10 per second. We're using PG 8.3.1 on a machine with two dual core 2.4Ghz XEON CPUs, 16 GB of memory and Debian Linux. The machine is completely devoted to PG, nothing else runs on the box. > > Lately we're getting a lot of exceptions from the Java process that does these inserts: "An I/O error occured while sending to the backend." No other information is provided with this exception (besides the stack trace of course). What do your various logs (pgsql, application, etc...) have to say? Can you read a java stack trace? Sometimes slogging through them will reveal some useful information. > The pattern is that for about a minute, almost every insert to this 22 GB table results in this exception. After this minute everything is suddenly fine and PG happily accepts all inserts again. We tried to nail the problem down, and it seems that every time this happens, a select query on this same table is in progress. This select query starts right before the insert problems begin and most often right after this select query finishes executing, inserts are fine again. Sometimes though inserts only fail in the middle of the execution of this select query. E.g. if the select query starts at 12:00 and ends at 12:03, inserts fail from 12:01 to 12:02. Sounds to me like your connections are timing out (what's your timeout in jdbc set to?) A likely cause is that you're getting big checkpoint spikes. What does vmstat 10 say during these spikes? If you're running the sysstate service with data collection then sar can tell you a lot. If it is a checkpoint issue then you need more aggresive bgwriter settings, and possibly more bandwidth on your storage array. Note that you can force a checkpoint from a superuser account at the command line. You can always force one and see what happens to performance during it. You'll need to wait a few minutes or so between runs to see an effect.