tag:blogger.com,1999:blog-14455177.post5620026616702588228..comments2024-03-07T18:57:25.977+01:00Comments on Mikael Ronstrom: MySQL Thread Pool: SummaryMikael Ronstromhttp://www.blogger.com/profile/07134215866292829917noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-14455177.post-46743691596007938902011-10-28T01:38:42.512+02:002011-10-28T01:38:42.512+02:00Wlad,
I hope I have supplied sufficient informatio...Wlad,<br />I hope I have supplied sufficient information on my thoughts in the area now to answer that. I still beg to differ, there is still things we want in the MySQL Thread Pool which isn't available in the OS solutions. But I already mentioned these things in my blogs so no need to repeat it all again.Mikael Ronstromhttps://www.blogger.com/profile/07134215866292829917noreply@blogger.comtag:blogger.com,1999:blog-14455177.post-91380705721117952862011-10-28T01:31:26.915+02:002011-10-28T01:31:26.915+02:00I fail to understand how MySQL threadpool is diffe...I fail to understand how MySQL threadpool is different from a generic one. IO integration,filling cores to the max, ensure forward progress if task stall, is that what generic threadpool does, and OS-integrated one has a much better information to consider when making decisions, it has the knowlegde of any single wait, not what one would tell it via thd_begin_wait(). Given that both Windows threadpool and Grand Central Dispatch on Lion now also have task priorization if required, I fail to see see why this would not be a perfect fit.wladhttps://www.blogger.com/profile/14657227220070201326noreply@blogger.comtag:blogger.com,1999:blog-14455177.post-72859882708747084552011-10-28T00:30:28.291+02:002011-10-28T00:30:28.291+02:00Hi Wlad,
The model we designed wasn't a workar...Hi Wlad,<br />The model we designed wasn't a workaround. We looked at several options of how to implement things in various OSs and we also did consider Windows IO completion ports.<br /><br />The choices we did was based on the requirements we had and also on discovering that the solution scaled well fairly independent of the way the OS solved the problems.<br /><br />There isn't any solution in any OS that provides a perfect fit for the requirements of the MySQL thread pool.Mikael Ronstromhttps://www.blogger.com/profile/07134215866292829917noreply@blogger.comtag:blogger.com,1999:blog-14455177.post-48175734243486693142011-10-27T23:59:14.314+02:002011-10-27T23:59:14.314+02:00Mikael, don't you think that the requirement &...Mikael, don't you think that the requirement "split threads into group.." was not a requirement, but rather a workaround for the sorry state of asynchronous IO on a single operating system Linux. epoll, used in multithreaded environemnts has pathetic performance. Some other OSes (especially those where context switch costs more than on Linux) have a much better async IO builtin in the OS. Windows IO completion ports are done well, and provide anything one would need for a threadpool - LIFO wakeup for threads waiting on them, concurrency limiting (*not* letting all threads run, if runnable thread count > parameter). Well, Windows provides also the threadpool itself. So does OSX with Grand Central Dispatch. Linux with its thundering herd wakeup-all-threads-waiting-on-epoll and FIFO scheduler activation is a joke, compared to others (I read on LKML, and many patches were suggested to fix the above problems, and all were rejected, due to some subtle semantics change). Anyway, my point is that you (or actually Kelly couple of years back from now) seem to have built a system to workaround Linux limitations. Why did not you plan to use something better if it is available?wladhttps://www.blogger.com/profile/14657227220070201326noreply@blogger.com