| From: | Dave Crooke <dcrooke(at)gmail(dot)com> |
|---|---|
| To: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> |
| Cc: | Dmitri Girski <mitek17(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: pg_connect takes 3.0 seconds |
| Date: | 2010-01-07 20:13:08 |
| Message-ID: | ca24673e1001071213y57e6fd73q757bffd98ef39baa@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2010-01-07 20:16:39 | Re: query looping? |
| Previous Message | Nikolas Everett | 2010-01-07 18:52:40 | Re: Joining on text field VS int |