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.
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 li
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
On Wed, Jan 6, 2010 at 7:44 PM, 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
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.
Cheers,
Dmitri.
On Tue, J
Dave Crooke wrote:
The fact that the delays are clustered at (3 + 0.2 n) seconds, rather
than a distributed range, strongly indicates a timeout and not
(directly) a resource issue.
3 seconds is too fast for a timeout on almost any DNS operation, unless
it has been modified, so I'd suspect it'
The fact that the delays are clustered at (3 + 0.2 n) seconds, rather than a
distributed range, strongly indicates a timeout and not (directly) a
resource issue.
3 seconds is too fast for a timeout on almost any DNS operation, unless it
has been modified, so I'd suspect it's the TCP layer, e.g. pe
On Tue, Jan 5, 2010 at 11:50 PM, Craig Ringer
wrote:
> Wireshark is your friend.
+1. I think if you put a packet sniffer on the interface you are
connecting from it will become clear what the problem is in short
order.
...Robert
--
Sent via pgsql-performance mailing list (pgsql-performance@po
On Wed, 6 Jan 2010, Dmitri Girski wrote:
On the other hand, if I use ip addresses this should not attract any possible
issues with
DNS, right?
Not true. It is likely that the server program you are connecting to will
perform a reverse DNS lookup to work out who the client is, for logging or
Dmitri Girski wrote:
> Hi Andy,
>
> I tried 2 connections strings:
> - server name (DB1), which is listed in all machines hosts files.
> - ip address.
>
> There is no difference in both methods, still I have 5-7 pg_connects which
> last around 3 seconds.
Don't rule out reverse DNS issues (such
On Tue, Jan 5, 2010 at 8:49 PM, Dmitri Girski wrote:
> Hi Tom,
> The timing is around 3.0 seconds
> Time=3.0037
> Time=3.4038
> Time=3.0038
> Time=3.004
> Time=3.2037
> Time=3.0039
> Time=3.0034
> Time=3.0034
> Time=3.2039
> Time=3.0044
> Time=3.8044
> Time=3.2034
>
> I don't think that it could r
Hi Greg,
Thank you for idea, reading about checkpints & tuning was very useful.
I had a checkpoints logging turned on. I studied a couple of days logs and I
there is no clear dependency on checkpoint write. Sometimes it is within a
vicinity of 3 seconds CONNECT, sometimes well off it.
Also the p
Hi Tom,
The timing is around 3.0 seconds
Time=3.0037
Time=3.4038
Time=3.0038
Time=3.004
Time=3.2037
Time=3.0039
Time=3.0034
Time=3.0034
Time=3.2039
Time=3.0044
Time=3.8044
Time=3.2034
I don't think that it could relate to DNS problem as I tried 2 methods which
does not use name resolution ( hosts
Thank you for reply , Andy!
I tried both cases: server name which is listed in hosts file and ip address
( 192.168.2.2) - no difference so far.
Cheers,
Dmitri.
On Wed, Jan 6, 2010 at 2:03 AM, Andy Colson wrote:
> On 1/4/2010 8:12 PM, Dmitri Girski wrote:
>
>> Hi everybody,
>>
>> I am running a
Hi Scott,
Thank you pointers, I've spoken to the network guy, he will help to monitor
connections on the firewall.
On the other hand, if I use ip addresses this should not attract any
possible issues with DNS, right?
Thanks!
Dmitri.
On Wed, Jan 6, 2010 at 9:32 AM, Scott Carey wrote:
> Delays
Hi Andy,
I tried 2 connections strings:
- server name (DB1), which is listed in all machines hosts files.
- ip address.
There is no difference in both methods, still I have 5-7 pg_connects which
last around 3 seconds.
Cheers,
Dmitri.
On Wed, Jan 6, 2010 at 2:03 AM, Andy Colson wrote:
> On 1
Delays that are almost exactly 3 seconds over a network are almost always
some sort of network configuration issue.
Inside a datacenter, mis-configured load balancers or routers can cause low
level network issues that result in intermittent network delays of exactly 3
seconds (a loop in a routing
On 1/4/2010 8:12 PM, Dmitri Girski wrote:
Hi everybody,
I am running a PostgreSQL server 8.3.5 with a pretty much standard config.
The web application server which runs Apache 1.3/PHP2.9 has an
intermittent problem:
pg_connect takes exactly 3.0 seconds. The usual connection time is 0.0045.
The
Dmitri Girski writes:
> I am running a PostgreSQL server 8.3.5 with a pretty much standard config.
> The web application server which runs Apache 1.3/PHP2.9 has an intermittent
> problem:
> pg_connect takes exactly 3.0 seconds. The usual connection time is 0.0045.
> The long request happens at a
Dmitri Girski wrote:
I am running a PostgreSQL server 8.3.5 with a pretty much standard config.
The web application server which runs Apache 1.3/PHP2.9 has an
intermittent problem:
pg_connect takes exactly 3.0 seconds. The usual connection time is 0.0045.
The long request happens at approxima
20 matches
Mail list logo
