Re: pg_connect takes 3.0 seconds

Поиск
Список
Период
Сортировка
От Dmitri Girski
Тема Re: pg_connect takes 3.0 seconds
Дата
Msg-id daed64561001090836l2aadd92awb1e4413e3cf27066@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_connect takes 3.0 seconds  (Dave Crooke <dcrooke@gmail.com>)
Список pgsql-performance
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 <dcrooke@gmail.com> 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

В списке pgsql-performance по дате отправления:

Предыдущее
От: Pierre Frédéric Caillaud
Дата:
Сообщение: Re: PG optimization question
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Joint index including MAX() ?