[add CC internals@]
On 2 Apr 2007, at 08:52, Joseph Benden wrote:
> I have created a bug entry for this.
>
> http://bugs.mysql.com/bug.php?id=27587
>
> I would be interested in creating an initial fix which could be
> scrutinized by others. :) I have clients using older MySQL versions
> in production (3.0, 4.0 and 5.0), so I am also very interested in
> back-porting the final fix for these clients.
>
> To get the fix underway, should I use the current MySQL 5.0.37 code
> or is an SVN/CVS tree available somewhere?
We use BitKeeper internally, and we historically told people to use
the free BitKeeper client and to see "download" at
http://mysql.bkbits.net/
. Honestly though, the free client is designed to be clunky, and
you'll probably be better off importing a snapshot into your favorite
tool and using that to generate a diff to send us.
http://dev.mysql.com/downloads/mysql/5.0.html#source
- chad
> Chad MILLER wrote:
>> Hi Joseph.
>>
>> On 1 Apr 2007, at 14:03, Joseph Benden wrote:
>>> I'm trying to squeeze all the performance possible from every
>>> piece of my Solaris systems. The last piece that is bugging me
>>> is the high number of system calls experienced on the machines.
>>> In analyzing the web server, I found the problem was the read()
>>> system call. Next, I wanted to know what sizes were being read
>>> and where from. It turns out the read()s are from the
>>> mysqlclient library and are 4 byte reads.
>>>
>>> value ------------- Distribution ------------- count
>>> 0 | 0
>>> 1 |@@@@@ 3447
>>> 2 |@ 616
>>> 4 |@@@@@@@@@@@@@@@@@@@ 12531
>>> 8 |@ 626
>>> 16 |@@@@@@@@ 4966
>>> 32 |@@ 1158
>>> 64 | 153
>>> 128 | 29
>>> 256 | 15
>>> 512 | 5
>>> 1024 | 17
>>> 2048 | 0
>>> 4096 | 0
>>> 8192 |@@@@ 2667
>>> 16384 | 0
>>>
>>>
>>> Upon further research with dtrace, I've found these read()s to
>>> correspond with the MySQL protocol packet header being read().
>>>
>>> I was wondering why a buffered approach wasn't taken. ie: A
>>> general buffered read() of everything possible from the wire and
>>> the protocol code asking for the number of bytes from that
>>> buffered area. I feel that in doing this many system calls could
>>> be reduced, which would increase the speed of using the library.
>>
>>
>> While we are more sensitive to excessive syscalls since Bug#22943,
>> we still have room for improvement. The "vio" interface that we
>> use for (nearly) all I/O is nicely modular, but does need some
>> attention, and a buffer sounds like an excellent project that
>> shouldn't take very long and is rather cool. This would have wide-
>> reaching effects, all the way into the server; this is not a
>> client-only problem.
>>
>> Joseph, with your research so far, you are probably in a great
>> position to create heuristically good read() buffer sizes. Do you
>> feel comfortable taking on such a project?
>>
>> If not, I'm sure someone else on this list would gladly take it.
>>
>> In any case, this should be entered into our bug-tracking system.
>> Do you mind adding it, Joseph, along with any more detailed output
>> from your tracing tool?
>>
>> - chad
>>
>> --
>> Chad Miller, Software Developer
>> chad@stripped
>> MySQL Inc., www.mysql.com
>> Orlando, Florida, USA 13-20z,
>> UTC-0400
>> Office: +1 408 213 6740 sip:
>> 6740@stripped
>>
>>
--
Chad Miller, Software Developer chad@stripped
MySQL Inc., www.mysql.com
Orlando, Florida, USA 13-20z, UTC-0400
Office: +1 408 213 6740 sip:6740@stripped
Attachment: [application/pgp-signature] This is a digitally signed message part PGP.sig
| Thread |
|---|
| • Re: added bug. SVN? was, Re: mysqlclient performance with syscalls | Chad MILLER | 2 Apr |
