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>
index | next in thread | previous in thread | raw e-mail
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.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46EFED9B.7010300>