Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 9FDDE633958 for ; Sat, 9 Jan 2010 12:37:22 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 13989-09 for ; Sat, 9 Jan 2010 16:37:11 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by mail.postgresql.org (Postfix) with ESMTP id B40A563385E for ; Sat, 9 Jan 2010 12:37:11 -0400 (AST) Received: by pwi15 with SMTP id 15so680903pwi.3 for ; Sat, 09 Jan 2010 08:37:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type; bh=HahluSa+IZJgYWcQ4VH6ptViKEu9PdaCqrah7F9G75Y=; b=ltXDwSGAsJvxes/Wf+MySI3KGO2ChcSoeCxv2jzW+ddHMIdO0giZOI3ATtPOE/ijr6 zV2pg5UrwnVMEcJ9FvRypFvfkZ0gw14Haz01ZJvqvMA+y+ORMfyjbwh+RC8GJJc0axM1 GiPjs5Tu++CNteHrCHNa61tuOP1UQCCJg2e1s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=pCBXkLICQ6T7RGqVl6tEfiMttl2FJWcWbu/MVCqoUDpEwu5wBLlovaCOmxE+E9Y2sJ lesjovPMRiES+r58sFdpIxvtzLW1iLEDdKDDp1R0gLsTX2WUFAZqBrFBPLFo2hLeea+O xEZNR/em/Am9eb64qxCa3P+hlUtvMiC3DGCCk= MIME-Version: 1.0 Received: by 10.114.243.14 with SMTP id q14mr3982578wah.168.1263055030139; Sat, 09 Jan 2010 08:37:10 -0800 (PST) In-Reply-To: References: <4B458FD0.8020205@postnewspapers.com.au> From: Dmitri Girski Date: Sun, 10 Jan 2010 03:36:50 +1100 X-Google-Sender-Auth: 06e163c1aedb17fe Message-ID: Subject: Re: pg_connect takes 3.0 seconds To: Dave Crooke Cc: Craig Ringer , pgsql-performance@postgresql.org Content-Type: multipart/alternative; boundary=0016e64ca916674624047cbdeaaa X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-0.447 tagged_above=-10 required=5 tests=AWL=2.151, BAYES_00=-2.599, HTML_MESSAGE=0.001 X-Spam-Level: X-Archive-Number: 201001/168 X-Sequence-Number: 37048 --0016e64ca916674624047cbdeaaa Content-Type: text/plain; charset=ISO-8859-1 Thanks for advice, Dave! This saga ended in an unexpected way: the firewall died. Since the replacement firewall installed I have not seen any 3 seconds connects. Well, there was no real load so far, but I will keep checking. Thanks to everyone replied, it was very helpful. Cheers, Dmitri. On Fri, Jan 8, 2010 at 7:13 AM, Dave Crooke wrote: > Oops, I meant to mention this too .... virtually all GigE and/or server > class NICs do TCP checksum offload. > > Dimitri - it's unlikely that you have a hardware issue on the NIC, it's > more likely to be a cable problem or network congestion. What you want to > look for in the tcpdump capture is things like SYN retries. > > A good way to test for cable issues is to use a ping flood with a large > packet size. > > Cheers > Dave > > Hang on a sec. You need to ignore bad checksums on *outbound* packets, >> because many (most?) Ethernet drivers implement some level of TCP >> offloading, and this will result in packet sniffers seeing invalid checksums >> for transmitted packets - the checksums haven't been generated by the NIC >> yet. >> >> Unless you know for sure that your NIC doesn't do TSO, ignore bad >> checksums on outbound packets from the local interface. >> >> -- >> Craig Ringer >> >> >> -- >> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org >> ) >> To make changes to your subscription: >> http://www.postgresql.org/mailpref/pgsql-performance >> > > -- @Gmail --0016e64ca916674624047cbdeaaa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks for advice, Dav= e!

This saga ended in an unexpected way: the firewall died.=A0<= /font>
Since the replacement firewall installed I hav= e not seen any 3 seconds connects. Well, there was no real load so far, but= I will keep checking.


Thank= s to everyone replied, it was very helpful.

Cheers,
Dmitri.




On Fri, Jan 8, 2010 at 7:13 AM, Dave Crooke <dcrooke@gmail.com> wrote:
Oops, I meant to mention this too .... virt= ually all GigE and/or server class NICs do TCP checksum offload.

Dim= itri - it's unlikely that you have a hardware issue on the NIC, it'= s more likely to be a cable problem or network congestion. What you want to= look for in the tcpdump capture is things like SYN retries.

A good way to test for cable issues is to use a ping flood with a large= packet size.

Cheers
Dave

<= div class=3D"gmail_quote">
Hang on a sec. You need to ignore bad checksums on *outbound* packets, beca= use many (most?) Ethernet drivers implement some level of TCP offloading, a= nd this will result in packet sniffers seeing invalid checksums for transmi= tted packets - the checksums haven't been generated by the NIC yet.

Unless you know for sure that your NIC doesn't do TSO, ignore bad check= sums on outbound packets from the local interface.

--
Craig Ringer


--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance




--
@Gmail
--0016e64ca916674624047cbdeaaa--