Date: Tue, 18 Sep 2007 11:24:11 -0400 From: "Philip M. Gollucci" <philip@ridecharge.com> To: "freebsd-questions@freebsd.org" <freebsd-questions@freebsd.org> Cc: Kris Kennaway <kris@FreeBSD.org> Subject: Re: MySQL config [WAS: ]uilding a new workstation - dual or quad-core CPU for FreeBSD 7? Message-ID: <46EFED9B.7010300@ridecharge.com> In-Reply-To: <46EF21C2.7010104@FreeBSD.org> References: <26ddd1750709141351i3646e9bdg8d8b7e93461167f9@mail.gmail.com> <bef9a7920709141441r5c228a8bu1fcf2ea15868c3c@mail.gmail.com> <26ddd1750709151014x2112b022r9bcb999fbf1e7e49@mail.gmail.com> <46EC270A.3020100@FreeBSD.org> <8cb6106e0709151421h7bfdeb6fo7dc671820294e9c7@mail.gmail.com> <46EC4F59.7070104@FreeBSD.org> <8cb6106e0709151435p72cd328by63895421f3a63ea4@mail.gmail.com> <46EC50DA.6000104@FreeBSD.org> <8cb6106e0709151446x4c54a520u2d5cd543ba1541e@mail.gmail.com> <46EC55B8.2090107@FreeBSD.org> <46EEE3ED.6080304@ridecharge.com> <46EF21C2.7010104@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Kris Kennaway wrote: > libthr has been around (and performing better than libkse) since the 5.x > days and has been recommended for use since 6.0. Yeah I knew it had been around -- missed the recommend part. >> sysctl kern.timecounter.choice >> kern.timecounter.choice: TSC(-100) ACPI-fast(1000) i8254(0) >> dummy(-1000000) >> >> sysctl kern.timecounter.hardware >> kern.timecounter.hardware: TSC I meant to say that this made a rather large difference. >> 3) /tmp is a md0 malloc backed device Eh -- I'll switch it. > > Should be swap backed, but it won't make much difference on your workload. > >> (I'm thinking of using tmpfs in 7.0 when I switch) > > tmpfs is not yet production-ready even though it performs better. Yeah that I knew, but I haven't had any issues with it on any of my desktops that run it. >> my.cnf >> innodb_thread_concurrency = 8 > > You want '0' or performance will suck. There's a basic architectural > flaw in how mysql handles non-zero concurrency values here (innodb > accesses are serialized by a global mutex that protects a counter to > check if it should try to allow more innodb concurrency. Duh.) > > Anyway, assuming your disks can keep up you should see a big performance > boost when you switch to 7.0. This is a fairly big "if" though: I don't > know if it's even feasible for a write-heavy database to saturate 8 CPUs > instead of being bottlenecked by disk speeds and leaving the CPUs mostly > idle. Ah boo!!! I have DBs that are SELECT heavy and those that are WRITE heavy. I suppose I'll attached the my.cnf I'm using. Is it worth having the port remove that recommendation from the /usr/local/share/mysql/*.cnf files ? -- ------------------------------------------------------------------------ Philip M. Gollucci (philip@ridecharge.com) c:323.219.4708 o:703.749.9295x206 Senior System Admin - Riderway, Inc. http://riderway.com / http://ridecharge.com 1024D/EC88A0BF 0DE5 C55C 6BF3 B235 2DAB B89E 1324 9B4F EC88 A0BF Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46EFED9B.7010300>