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
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
On Tue, Jan 5, 2010 at 11:50 PM, Craig Ringer
cr...@postnewspapers.com.au 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
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.
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
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,
On Wed, Jan 6, 2010 at 7:44 PM, Dmitri Girski mite...@gmail.com 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
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 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.
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
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
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
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 a...@squeakycode.net wrote:
On 1/4/2010 8:12 PM, Dmitri Girski wrote:
Hi everybody,
I
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 (
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
On Tue, Jan 5, 2010 at 8:49 PM, Dmitri Girski mite...@gmail.com 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
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 as a
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 long request happens at approximate rate
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
Dmitri Girski mite...@gmail.com 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
21 matches
Mail list logo
