Re: pg_connect takes 3.0 seconds
| От | Dave Crooke |
|---|---|
| Тема | Re: pg_connect takes 3.0 seconds |
| Дата | |
| Msg-id | ca24673e1001071213y57e6fd73q757bffd98ef39baa@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: pg_connect takes 3.0 seconds (Craig Ringer <craig@postnewspapers.com.au>) |
| Ответы |
Re: pg_connect takes 3.0 seconds
|
| Список | 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
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
В списке pgsql-performance по дате отправления: