Here comes the tcpdump (the server has IP 192.168.1.1 listening on port
3306 and the client has IP 192.168.1.99).
tcpdump on the server:
11:24:44.226373 IP 192.168.1.99.39028 > 192.168.1.1.3306: S
3068401272:3068401272(0) win 5840 <mss 1460,sackOK,timestamp 10592352
0,nop,wscal e 6>
11:24:44.226389 IP 192.168.1.1.3306 > 192.168.1.99.39028: S
3052139931:3052139931(0) ack 3068401273 win 5792 <mss
1460,sackOK,timestamp 10478 87 10592352,nop,wscale 7>
11:24:47.226673 IP 192.168.1.99.39028 > 192.168.1.1.3306: S
3068401272:3068401272(0) win 5840 <mss 1460,sackOK,timestamp 10595352
0,nop,wscale 6>
11:24:47.226715 IP 192.168.1.1.3306 > 192.168.1.99.39028: S
3052139931:3052139931(0) ack 3068401273 win 5792 <mss
1460,sackOK,timestamp 1048187 10592352,nop,wscale 7>
11:24:47.226957 IP 192.168.1.99.39028 > 192.168.1.1.3306: . ack 1 win 92
<nop,nop,timestamp 10595352 1048187>
11:24:47.227488 IP 192.168.1.99.39028 > 192.168.1.1.3306: F 1:1(0) ack 1
win 92 <nop,nop,timestamp 10595352 1048187>
11:24:47.227580 IP 192.168.1.1.3306 > 192.168.1.99.39028: F 1:1(0) ack 2
win 46 <nop,nop,timestamp 1048187 10595352>
11:24:47.227810 IP 192.168.1.99.39028 > 192.168.1.1.3306: . ack 2 win 92
<nop,nop,timestamp 10595353 1048187>
tcpdump on the client:
11:24:44.045735 IP 192.168.1.99.39028 > 192.168.1.1.3306: S
3068401272:3068401272(0) win 5840 <mss 1460,sackOK,timestamp 10592352
0,nop,wscale 6>
11:24:47.045710 IP 192.168.1.99.39028 > 192.168.1.1.3306: S
3068401272:3068401272(0) win 5840 <mss 1460,sackOK,timestamp 10595352
0,nop,wscale 6>
11:24:47.045911 IP 192.168.1.1.3306 > 192.168.1.99.39028: S
3052139931:3052139931(0) ack 3068401273 win 5792 <mss
1460,sackOK,timestamp 1048187 10592352,nop,wscale 7>
11:24:47.046015 IP 192.168.1.99.39028 > 192.168.1.1.3306: . ack 1 win 92
<nop,nop,timestamp 10595352 1048187>
11:24:47.046541 IP 192.168.1.99.39028 > 192.168.1.1.3306: F 1:1(0) ack 1
win 92 <nop,nop,timestamp 10595352 1048187>
11:24:47.046845 IP 192.168.1.1.3306 > 192.168.1.99.39028: F 1:1(0) ack 2
win 46 <nop,nop,timestamp 1048187 10595352>
11:24:47.046880 IP 192.168.1.99.39028 > 192.168.1.1.3306: . ack 2 win 92
<nop,nop,timestamp 10595353 1048187>
I can also provide a strace if required (alternatively you can find the
tcpdump and the strace in my original posting, e.g.
http://marc.info/?l=linux-net&m=120214156112338&w=2).
Kind regards,
Leo
H. Willstrand wrote:
On Mon, Mar 31, 2008 at 11:33 AM, Leo <neleo@xxxxxxx> wrote:
Yes, we have changed the back_log settings in my.cnf. We also tried
various combinations of the kernel parameters you mentioned in your
email - without success.
Have you made any changes on the client (=webserver)? Perhaps it's not a
problem of the server (=mysql). As I figured out in my original posting
it looks as if the client didn't receive the SYN/ACK package from the
server (keep in mind that it is reproducable with lo interface,
therefore it's not a hardware problem with cables, switches, ...):
"When you look at the TCP pakets transmitted between server and client
(tcpdump) you will see that the client sends a SYN and the server
answers with a SYN/ACK. However the client will never receive the
SYN/ACK. Therefore the client resends a SYN after exactly 3 seconds. The
server answers with a SYN/ACK again and this time the client receives
the paket. Now the connection is working."
Hi!
Can you please post that tcpdump? (Just to check the first ACK).
Br H.Willstrand
On friday I received an email from another user having the same problem.
As I mentioned in my last email: we are not alone ;-)
Many thanks for your help.
Kind regards,
Leo
Marlon de Boer wrote:
> Leo wrote:
>
>> We discovered the same problem two month ago (even 3 sec connect
>> problems between webserver and mysql backend). I have posted it to
>> the list (subject "TCP connect hangs for 3 seconds", 2008-02-04)
>> but didn't get any answer yet. When I read your mail it was a
>> flicker of hope.
>>
>> This is not a mysql issue! You can easily reproduce it with a few
>> lines of C code (see below, it's similar to your program) running
>> against any open port on the server (e.g. netcat: nc -k -l
>> <PORTNUMBER>). We have also tested it on different hardware and
>> kernel versions (up to 2.6.24.4) and we can deliver further
>> information if requested ...
>>
>> Unfortunately the kernel parameter you mentioned in your second
>> mail (net.core.somaxconn) didn't solve the problem.
>>
>> I think there are many other people out there having this problem
>> unconsciously. Can anybody help?
>>
>>
> I used the c code below to test the server side. After playing with
> the kernel settings, some code,
> setsockopt(sd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt)) and
> listen(sd, 8192) the timeouts disappeared.
>
> Did you changed the settings in mysql.cnf? back_log = 8192, and
> restarted the mysql daemon? Else try to raise it to 16384 or even higher.
>
> Regards
> Marlon
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
