Date: Tue, 18 Sep 2007 02:54:26 +0200 From: Kris Kennaway <kris@FreeBSD.org> To: "Philip M. Gollucci" <philip@ridecharge.com> Cc: "josh.carroll@gmail.com" <josh.carroll@gmail.com>, Maxim Khitrov <mkhitrov@gmail.com>, Aryeh Friedman <aryeh.friedman@gmail.com>, "freebsd-questions@freebsd.org" <freebsd-questions@freebsd.org> Subject: Re: Building a new workstation - dual or quad-core CPU for FreeBSD 7? Message-ID: <46EF21C2.7010104@FreeBSD.org> In-Reply-To: <46EEE3ED.6080304@ridecharge.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
Philip M. Gollucci wrote: > Kris Kennaway wrote: >> Josh Carroll wrote: >>>> That's good to know. You should be using libthr for threaded >>>> performance though :) That benchmark is probably almost all userland >>>> though, so performance may not suffer much from libpthread. >>> Oh I wasn't sure if libthr was the preferred thread library for 6.2 >>> also (I'd heard that was the case for -CURRENT). >>> >>> I should look into whether ffmpeg can be built with libthr instead and >>> compare performance. Somewhat off topic, so I'll leave it at that, but >>> thanks again for the great info. I'm really looking forward to >>> 7.0-RELEASE, obviously :) >> Yeah, it is preferred on 6.x too (libkse has truly atrocious >> performance). It's trivial to change it over, just add an entry to >> /etc/libmap.conf: > Really? I didn't you you were supposed to switch until 7.0 -- were the > libthr chnages MFC'd and I missed it ? libthr has been around (and performing better than libkse) since the 5.x days and has been recommended for use since 6.0. > I've read > http://people.freebsd.org/~kris/scaling/mysql.html > and > http://wiki.freebsd.org/MySQL > > I've been following the discussions on this pretty closely on lists. > > PU: Intel(R) Xeon(R) CPU E5310 @ 1.60GHz (1597.53-MHz > K8-class CPU) > Origin = "GenuineIntel" Id = 0x6f7 Stepping = 7 > > Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > > Features2=0x4e33d<SSE3,RSVD2,MON,DS_CPL,VMX,TM2,<b9>,CX16,<b14>,<b15>,<b18>> > AMD Features=0x20100800<SYSCALL,NX,LM> > AMD Features2=0x1<LAHF> > Cores per package: 4 > real memory = 9395240960 (8960 MB) > avail memory = 8291323904 (7907 MB) > FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs > > uname -a > FreeBSD hobbes.dca2.prod.rws 6.2-RELEASE FreeBSD 6.2-RELEASE #0: > root@portnoy.cse.buffalo.edu:/usr/obj/usr/src/sys/SMP amd64 > > I'll recompile the kernel eventually to slim it down. > > using 4BSD scheduler since its 6.2 > > ls -1d /var/db/pkg/mysql* > mysql-client-5.0.45 > mysql-scripts-5.0.45 > mysql-server-5.0.45 > > ldd /usr/local/libexec/mysqld > mysqld: > libz.so.3 => /lib/libz.so.3 (0x800a5c000) > libwrap.so.4 => /usr/lib/libwrap.so.4 (0x800b70000) > libcrypt.so.3 => /lib/libcrypt.so.3 (0x800c79000) > libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x800d92000) > libm.so.4 => /lib/libm.so.4 (0x800f89000) > libpthread.so.2 => /lib/libpthread.so.2 (0x8010a5000) > libc.so.6 => /lib/libc.so.6 (0x8011d0000) > > > sysctl kern.timecounter.choice > kern.timecounter.choice: TSC(-100) ACPI-fast(1000) i8254(0) > dummy(-1000000) > > sysctl kern.timecounter.hardware > kern.timecounter.hardware: TSC > > Disks are: > 1) RAID1(2 disks) OS array with mysql logs, replication logs, > and innodb logs. > 2) RAID1+0(6disks) innodb mysql data. > 3) /tmp is a md0 malloc backed device 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. > using libmap.conf to use libc_r, libpthread, and libthr were all about > equal actually for insert heavy operations. > > 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. Kris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46EF21C2.7010104>