MySQL Lists are EOL. Please join:

List:General Discussion« Previous MessageNext Message »
From:Michael Widenius Date:March 30 1999 10:07am
Subject:Linux Threads and socket options
View as plain text  
>>>>> "Chris" == Chris Wilson <cmw32@stripped> writes:

Chris> Hi,
Chris> I don't really know who to ask on this one, because mysql is unsupported
Chris> (obviously, as free software), but maybe someone on this list can tell me,
Chris> or at least point me in the right direction.


I first want to clear up one thing;  MySQL is not unsupported !
TCX provides commerical support to MySQL.

You can find information about the MySQL license prices and the MySQL
support levels at

MySQL is also only free for inhouse use;
The very reasonable license and the fact that is distributed in source 
makes it easy to regard MySQL as free software, even if MySQL is a
commercial product.

Chris> MySQL has the option to set TCP_NODELAY on the server's listening socket,
Chris> however, this is only compiled in on FreeBSD:

Chris> #if defined(IPTOS_THROUGHPUT) && !defined(HAVE_LINUXTHREADS) /* For
Chris> FreeBSD */
Chris>   if (fd > 0)
Chris>   {
Chris> #ifndef __EMX__
Chris>     int tos = IPTOS_THROUGHPUT;
Chris>     if (!setsockopt(fd, IPPROTO_IP, IP_TOS, (void*) &tos, sizeof(tos)))
Chris> #endif
Chris>     {
Chris>       int nodelay = 1;
Chris>       if (setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, (void*) &nodelay,
Chris>                      sizeof(nodelay)))
Chris>       {
Chris>         DBUG_PRINT("warning",("Couldn't set socket option for fast
Chris> send"));
Chris>       }
Chris>     }
Chris>   }
Chris> #endif

Chris> This appears to be deliberately excluding the use of TCP_NODELAY on Linux
Chris> (presumably because of the Linux Threads package). What I want to know is,
Chris> whether there is a really good reason for NOT using TCP_NODELAY on Linux?
Chris> I have a strong suspicion that we are suffering severe performance hits at
Chris> our site because of this option. 

On Linux, I was on the assumtion that the use of NONBLOCK send/recieve 
should be enough;  We haven't however timed what happens if one enables the
above code for Linux...

Chris> I think this because running a query and sending the results to /dev/null
Chris> or a file takes 1.4 seconds. Sending the same query over the network
Chris> (100MBps) takes about 30 seconds and runs at 50k/s. tcpdump shows that
Chris> each packet sent by the server is immediately followed by an
Chris> acknowledgement (i.e. the server waits for acknowledgement before sending
Chris> another packet). TCP_NODELAY would seem to prevent this.

Chris> In any case I am about to remove the !defined(HAVE_LINUXTHREADS) condition
Chris> and run comparison benchmarks on the system (hopefully the benchmarks will
Chris> also pick up any possible data corruption). If anyone suspects that this
Chris> will cause data corruption, please could you let me know immediately
Chris> before I destroy all our company's data :-)

I think that removing the above test should be safe;  The MySQL protocol will
automaticly detect missing packets so it should notice if something
goes fatally wrong!  As all SQL commands are sent as clear text, it's
very unlikely that you will corrupt any data!

You can also try running the client with --compression;  The
uncompress code should detect any corruption in the real data!

Linux Threads and socket optionsChris Wilson30 Mar
  • Linux Threads and socket optionsMichael Widenius30 Mar
  • Support (Was: Linux Threads and socket options)Fred Read30 Mar
Re: Linux Threads and socket optionsEd Carp31 Mar
  • Re: Linux Threads and socket optionsMichael Widenius31 Mar