From: Craig Ringer <craig@postnewspapers.com.au>
To: Dmitri Girski <mitek17@gmail.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: pg_connect takes 3.0 seconds
Date: Thu, 07 Jan 2010 15:40:00 +0800
Message-ID: <4B458FD0.8020205@postnewspapers.com.au> (raw)
In-Reply-To: <daed64561001061844q528adafeke89b78adb868b15a@mail.gmail.com>
References: <daed64561001041812s602a3098l686f630d6448835f@mail.gmail.com>
<daed64561001061844q528adafeke89b78adb868b15a@mail.gmail.com>
On 7/01/2010 10:44 AM, Dmitri Girski wrote:
> Hi everybody,
>
> Many thanks to everyone replied, I think we are on the right way.
> I've used tcpdump to generate the logs and there are a lot of dropped
> packets due to the bad checksum. Network guy is currently looking at the
> problem and most likely this is hardware issue.
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: craig@postnewspapers.com.au, mitek17@gmail.com
Subject: Re: pg_connect takes 3.0 seconds
In-Reply-To: <4B458FD0.8020205@postnewspapers.com.au>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox