Date: Thu, 11 Jan 2001 16:26:03 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: vallo@matti.ee Cc: mauri@inspiral.net (Lauri Laupmaa), smp@FreeBSD.ORG Subject: Re: mysql (smp) performance Message-ID: <200101111626.JAA16987@usr08.primenet.com> In-Reply-To: <20010110191412.B265@myhakas.matti.ee> from "Vallo Kallaste" at Jan 10, 2001 07:14:12 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> > After some fair amount of testing I came to conclusion that > > unfortunately mysql (both 3.22 and 3.23) performance is considerably > > slower on freebsd than linux...at least on stock install. > > > > I have used 4.x-STABLE systems, both on SMP and singleproc and linux > > 2.1/2.2 kernels. > > > > It seems that on SMP mysql doesn't scale well. (currently testing on > > dual 833 PIII and running on couple older dual systems) > > > > I'm interested if there is some magic to get mysql run faster ? > > Or should I use 5.x-CURRENT ? > > Do not use -current at this time, it's too unstable and doesn't help > you anyway. The case is very simple, you'll have to wait for a year > or so until SMP support matures, or switch to well-known OS wrt SMP > and database applications. I don't want to start flame war, but free > x86 Solaris seems reasonable if you have powerful hardware. For > second don't know, haven't used Linux for a long time, but I don't > believe it'll be better for databases running MP system. For two > processors only, who knows.. MySQL uses POSIX threads; on FreeBSD, POSIX threads do not scale to an increased number of processors when running SMP. On Linux, POSIX threads scale poorly to an increased number of processors, when compared to Solaris and similar OS implemenations. As a practical matter, you can install the Linux threads kernel module and library on FreeBSD, and get at least as "good" SMP threads scaling on FreeBSD as you would on Linux, but both platforms are a poor second to even the worst of the commercial SMP systems at this time. POSIX threads also have some serious limitations, where the designers of the API exposed OS implementation issues specific to the reference platforms, all of which were System V UNIX variants. One major example of this is preallocation of fixed size stacks, which is not really necessary even on SVR4 systems, so long as they postdate Steve Baumel's VM work as of SVR4.2 (even on earlier implementations, it's pretty trivial to establish a guard page on a region, and auto-grow it by taking the fault in user space using a signal handler). Really, most people using threads should go back to the drawing board, and select a design that doesn't require threads. In any case, I have to agree here with the Solaris recommendation probably being your best bet for optimum SMP scalability at this time, at least as long as you don't go over 4 processors. For higher scaling, you will need to wait until FreeBSD completes the work already designed, but not yet implemented, or until another SMP OS threads support matures beyond the 4 CPU limit that comes from poor scheduling and too large a conflict domain brought about by unnecessarily over-shared resources. PS: I can't really see ythis being a real problem, if you are using MySQL as your engine; you will hit engine contention limits well before that level of scaling anyway. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200101111626.JAA16987>