[clue-tech] MySQL server reply packets delayed/lost under network congestion?

[Jim Ockers]

Hi Chris,

Thank you for the out-of-the-box idea.  If MySQL was trying to do 
inverse DNS it would certainly fail the way you describe because we have 
not set it up.  However I am not sure about that because when the link 
is not saturated, MySQL responds right away to the same requests or 
queries.  I will try adding a /etc/hosts entry on the linux server end 
for the client IP address and see if it is any better.

Thanks,
Jim

chris fedde wrote:
> Having read through this thread I begin to wonder if it is a DNS
> issue.  mysql may be looking for and failing to find reverse dns
> entries.  The characteristic for this particular problem is a 90
> second delay from the tcp connection till the response banner.
>
> You can check to see if this is the issue using tcpdump.
>
> On Sun, Nov 8, 2009 at 9:17 PM, Jim Ockers <ockers at ockers.net> wrote:
>   
>> Hi Dave,
>>
>> David L. Anselmi wrote:
>>     
>>> Jim Ockers wrote:
>>>       
>>>> Whenever there is sustained high bandwidth network traffic over the PPP
>>>> link (such as downloading a large e-mail attachment, or streaming video) the
>>>> mysql connections all start to time out because response packets from the
>>>> server are not received at the client.  I observed this by doing a simple
>>>> "telnet server 3306" and observed that the MySQL banner response with
>>>> version number was delayed by several seconds or until the bandwidth-hogging
>>>> stopped.
>>>>
>>>> What I don't understand is why I can still transfer data from other
>>>> servers on the Linux system, such as "net view \\server" and "dir
>>>> \\server\sharename" (using the Windows redirector to talk to Samba on the
>>>> Linux system).  Also the apache web server on the Linux system responds
>>>> normally, both from a web browser and also in response to "telnet server 80"
>>>> and then "GET / HTTP/1.0".
>>>>         
>>> I assume that other services are delayed like the MySQL banner.  Most of
>>> what you tried though would use fairly small responses (one packet, even?)
>>> so maybe the MySQL protocol is more verbose.
>>>
>>>       
>> No, actually the only service that is delayed is MySQL response packets
>> including the banner.  Apache responds right away to a GET / HTTP/1.0
>> request, samba responds right away to a Windows redirector request, FTP
>> responds right away, and so forth.  MySQL is the only one that seems to take
>> an unreasonably long time to respond when there is something hogging the
>> bandwidth.
>>     
>>> It seems that clients have several timeouts available:
>>>
>>> http://dev.mysql.com/doc/refman/5.1/en/mysql-options.html
>>>
>>> Maybe the protocol takes too long in some cases.
>>>       
>> I'm not too sure about that, but since the banner is delayed I wonder if
>> MySQL has some sort of built-in congestion management or something.
>>
>> Thanks though,
>> Jim
>>
>>
>> _______________________________________________
>> clue-tech mailing list
>> clue-tech at cluedenver.org
>> http://www.cluedenver.org/mailman/listinfo/clue-tech
>>
>>     
> _______________________________________________
> clue-tech mailing list
> clue-tech at cluedenver.org
> http://www.cluedenver.org/mailman/listinfo/clue-tech
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://cluedenver.org/pipermail/clue-tech/attachments/20091109/18856173/attachment.html